tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Status of revivesa

On Mon, Sep 29, 2008 at 09:16:56PM +0200, Quentin Garnier wrote:
> On Mon, Sep 29, 2008 at 11:43:17AM -0700, Bill Stouder-Studenmund wrote:
> > On Mon, Sep 29, 2008 at 10:39:18AM -0400, Christos Zoulas wrote:
> [...]
> > What still isn't clear to me is what exactly the negatives are of 
> > revivesa.
> > 
> > The biggest one I'm hearing is that a number of people HATE it. Flat out 
> > HATE it. I'm not really sure what to do with this one, since it's hard to 
> > understand. It's an emotion, and we usually try to stick to technical 
> > points.
> > 
> > The SA that's on revivesa is a kernel option. If you don't want it, don't 
> > enable it. If we find a catastrophic flaw in it (or security issue) late 
> > in the 5.0 release proces, we turn it off in the default kernels and tell 
> > people to only re-enable it with caution.
> > 
> > SA is not becoming, nor do I ever envision it becoming, the default 
> > threading out-of-the-box for NetBSD. Some sites may eventually prefer it, 
> > but that's a specialized situation. And something an admin would have to 
> > explicitly select.
> The main issue with SA is maintainability.  We failed to maintain it
> once, how likely are we to succeed now?  I have a lot of respect for
> your work on that, but I don't really see anyone maintaining it if for
> some reason you can't really do it anymore.
> Supposing it will be enabled by default, it won't be at risk of simply
> rotting;  but merely compiling doesn't equal working, especially for a
> piece of code that is affected by many different areas of the kernel,
> including MD ones.  And once 5.0 is out, it will hardly be tested until
> 6.0 is ready for release because you don't upgrade a system from a
> release to current the same way you upgrade a system from one release to
> another.  The GDT issue is a perfect example of that.

One thing I was thinking of doing after 5.0 was implementing the 
suggestion of supporting both threading libraries at once. As I understood 
it, the idea is to add the old SA libpthread back to current and have it 
install somewhere else. Say /usr/lib/sa/libpthread. Then you could just 
flip a sysctl and start using it.

The other alternative would be a pkg that does the same.

Take care,


Attachment: pgphmvifQRp1O.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index