Thor Lancelot Simon <tls@rek.tjls.com> writes:

> That said, I don't think newlock2 is going anywhere, so it seems to me
> our priorities should be:
>
> 1) Make ARM compile and get the present 1:1 threads working so they pass
>    the regression tests.

I understand Matt Thomas is working on this. I appreciate the effort,
although as of a few minutes ago it still doesn't compile.

> 2) Either cause them to perform acceptably for your application, or else
>    endeavor to get M:N back in a supported state for uniprocessors.

It has to be the later. The context switch overhead of 1:1 on ARM will
cause a severe performance degradation.

> It may be the case that we need to adjust the portmastership for the
> ARM ports to get these things done.

I believe that enough people are actively engaged to get this
particular thing done, if they follow through and finish.

However, seperate from that, y'all need to do something about your
portmasters because there's no responsiveness for ARM ports.

> I personally think ARM is an example of an architecture where there
> ought to be a portmaster-committee for the whole set of ARM ports,
> to put all the relevant expertise in one place, rather than one
> portmaster per port, who often drifts away because each individual
> port has few users.

You've got a chicken and egg problem with ARM. It's an important
architecture in the embedded world but you don't currently have a
whole lot of active developers for it. This means that people like us
have difficulty getting ports committed because no one has the
expertise to evaluate them. Not getting the ports committed means
you're less likely to get more developers, et cetera.

If you want NetBSD to be relevant to architectures other than x86 and
the end-of-lifers, you're going to have to change your processes to
accomodate that fact.