Sparc64 doesn't care about you, and you shouldn't care about Sparc64

Warner Losh imp at
Tue Nov 17 06:22:35 UTC 2015

On Mon, Nov 16, 2015 at 6:53 PM, Alfred Perlstein <bright at> wrote:

> On 11/14/15 9:16 AM, Warner Losh wrote:
>> On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers <
>> elizabeth at>
>> wrote:
>> You are seriously going to use "we're not NetBSD" as an argument?
>> You noticed I didn't reply to it. The argument is completely lame. FreeBSD
>> runs
>> today in a variety of markets. Some new, some not so new. The thing that
>> makes
>> each of these areas unique is that there's a thriving community around
>> them,
>> FreeBSD still runs well enough on these machines to get something done,
>> and
>> when things break, they get fixed in a timely manner.
>> Alpha was removed because it got broken by some changes, and stayed broken
>> for a long time despite repeated requests to fix it. Sparc64 is on the
>> cusp
>> of that:
>> some minor things are broken, but have been fixed. The current crisis is
>> due to
>> the end of life of gcc in the tree and its fallout coupled with some
>> neglect of the
>> port due to time constraints.
>> At first I was all for removal. With more data, I'm less sure. If the
>> promises are kept
>> made in this thread, it looks to remain viable for a while, though the
>> lack
>> of a
>> qemu-user solution means that packages for a slow platform (where they are
>> really quite useful) will remain limited. Maybe there's enough hardware
>> around
>> that third-party pkg repos can fill the gap, maybe not. I think we should
>> experiment
>> with this model and see what it produces. Give the branching of 11 as the
>> deadline
>> to show something viable...
> One of the things I never understood about FreeBSD's method of maintaining
> a port was the way the platform porting was done.  We really do things in a
> different manner than what my perception of other OSes is.
> My impression (please do correct me if I'm wrong) was that other OSes such
> as NetBSD and Linux had "platform maintainers".
> These maintainers were around to:
> 1) keep the ship sailing on those platforms
> 2) guide the general code base from becoming non-portable to other
> architectures (within reason).
> 3) drive the release of the architecture in question, helping the release
> engineer with image building and release testing.
> For point 1 above, what that meant to me was that let's say Linus or
> NetBSD in general wanted to do a major or minor change on a tier 1
> platform, then it was the responsibility of the *platform maintainers* to
> do the work on the non tier-1 platforms to keep them up to date.  Those
> "platform maintainers" kept those ships sailing and in return they got to
> be called "the $arch maintainer" which looks plenty good on a resume and
> also feels good for those that get excited for status.

I'm not sure how the people that actually take care of these things on
FreeBSD differ.  There are people
recognized as go-to people for the different ports that are fairly active
in the on-going issues that come
up with kernel code. Userland code doesn't seem to matter that much given
the platforms we support.

For PowerPC, you have Nathan W and Justin Hibbits. For mips, there's
Adrian, myself, Julie Mallet and a few
others. For arm there's a long cast of characters. For PC98 there's
Takahashi-san. For sparc64 there's Marius.
These people keep the ship sailing (or in some cases they remove the ship
form the tree). They advise
discussions about issues that are relevant to the platform, like cache
lines and cache coherence,
they call people out when they break these platforms or when people used to
big systems adjust the
tuning and break small systems.

> For point 2, let's say someone had a change that pushed some form of
> *completely* non-portable code into the base which would break a reasonable
> to support platform, then the "platform maintainer" would speak up and tell
> the general community "uh no, you can't do X on this platform, we need to
> rethink this".

People generally don't push this kind of code into the tree these days.
When they do, they get called
out on it. Some of them even listen to the calling out and fix things,
others don't and one of the
platform maintainers has to fix the stupid pushed into the tree. Sometimes
this happens right away
and sometimes there's a lag. sometimes it's code for newer versions of the
platform that break older
versions (or vice versa). Other times there's code from another platform
that breaks things.

USB is a textbook example of this happening. It went in, and didn't worth a
damn on arm or mips.
The ports maintainers of the arm and mips platforms tried to explain what
the issues were. It took
some time, but it got mostly worked out as the embedded folks got to know
USB issues, and hps
got to understand the issues with embedded hardware.

> For point 3, there may be a lag between release of the OS for tier 1
> (x86/x64) and the secondary architectures, but that is OK because the
> maintainer will eventually provide images themselves or in collaboration
> with the release engineer.

For this point, we've pushed the knowledge of how to build the images into
the release engineer. The
folks that are around that are using the port test the images. Sometimes
it's the port maintainers,
but recently it has been a large cast of characters for popular platforms.

> FreeBSD seems to take a different approach.  This approach is that someone
> (or some people) form a team to port to a platform.  These "platform
> porter" groups sole responsibility is to get a new architecture running.
> After it's mostly running they are mostly without responsibility, however
> we tend to give them the right of change-set veto in perpetuity of the
> marginal relevance of the ported to platform.

so like when did this actually happen?

> What this means is that instead of a assigning a title and ownership of
> the platform to someone, who maintains the status as "maintainer" by
> keeping that platform working.  By keeping the platform working I am saying
> that they would do items 1, 2 and 3 from the NetBSD/Linux list.  However,
> instead nearly immediately hoist the "platform maintenance" onto the
> general community of people that may not have access to the hardware in
> question.

Do you have a specific example of when we've done this? As far as I know,
based on powerpc, arm and
mips anyway, the people claiming to be maintainers are actively doing 1, 2
and helping RE do number
3 to varying degrees. As far as I know, they all have access to some or all
of the hardware they are
maintaining, and many of our power users participate in the process as well.

> Maybe this is just my perception, but it would seem to make a ton more
> sense to follow the NetBSD/Linux model which implies a somewhat decoupled
> release model (not all arches must come out on the same ) and assigning
> ownership and responsibility in exchange for status based on being the
> "platform maintainer".

So, rather than generalizations, be specific. Who do you think is claiming
to be a port maintainer, blocking
progress and needs to be replaced?

And what, beyond what the re@ does today, would you do differently? What do
we gain over what we do
for tier 1 platforms? Is there a platform wanting a release that isn't
getting one? mips has two different
groups that have put out releases for it, with one of them fading into the
background. Adiran is making
wifi builds available, already following this model you say we should
adopt. The japanese user groups are
putting out PC98 releases now that the re@ has dropped them (they never
really stopped in the mean
time). sparc64, powerpc, arm, i386 and amd64 are all released by re at . ia64
has been removed from the
tree. What other platforms are there? What else needs to be done.

> Finally it would be pretty obvious when everyone steps down or just
> doesn't participate in the release process that it may be time to sunset a
> platform.

That's why we are having the conversation about sparc64. It looked like it
might no longer be
participating in the normal process. Now, while there are some issues that
were identified with
sparc64, some of them are real (see qemu and difficulties building in the
cluster). Some of them
were just perception (the reduced numbers of commits to sparc64 didn't seem
to represent
a problem with the platform and the perceived issues had been cleared up)

So what, specific, actionable items do we as a project actually need to do
here? I'm sure there are some
and that we can improve our process. I'm having trouble teasing out what I,
as someone who dabbles
in arm and mips to varying degrees of 'maintainership' for different parts,
can do better or different.


> -Alfred

More information about the freebsd-sparc64 mailing list