Re: Status of revivesa

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Sep 28, 2008 at 02:57:25PM +0100, Mindaugas Rasiukevicius wrote:
> Quentin Garnier <cube%cubidou.net@localhost> wrote:
> > > Or, does the "compatibility problem" only affect chroot environments
> > > where any base libraries must not be updated?
> > 
> > Yes.  But all of that has already been discussed, you know.  You could
> > have read the archives.
> > 
> > The thing is, system administrators, which is our target in this
> > discussion, please keep that in mind, tend to be rather conservative
> > when it comes to upgrading machines.  The more conservative they can be,
> > the happier they will be.
> 
> Well, such "conservatism" could be called "laziness". Fair enough, and

I'd call it "reasonable upgrade plan".

> understandable. However, it does not mean that we should taint kernel with
> 3000+ lines (which invade all threading, and even mutex implementation) to

The whole diff is 8000 lines between revivesa and revivesa-base3.
Out of it there's 2700 lines in machdep which contains 2 new MD SA-specific
functions. The remaining code is to set/clear LP_SA_PAGEFAULT which is only
a few lines per port. I don't call this intrusive.

Off the remaining, there are 4027 lines of new SA-specific files, or
SA-specific functions.
This leaves us with about 1200 lines of MI diffs against existing
files/functions (including the syscall related stuff, which is
auto-generated), and most of it is calling a SA-specific function if
p->p_sa is not NULL, or a specific flag is set on proc or lwp. All this
occurs inside the existing proc/lwp locks. The mutex implementation is
indeed affected, by a 16-line change (including the #ifdef KERN_SA/#endif),
clearing/setting SA-specific flags. This change certainly can't hurt the
non-SA part of the kernel.

It's not as bad as you say, and certainly not so bad from a
software-engineering point of view. 

> support very specific compatibility needs. But yes, from my daily practise,
> often administrators just ignore software engineering points..
> 
> Looking at real world, business and administrators somehow survive with
> systems which break compatibility often. For critical production systems,

They also survive with linux or even windows ... if we don't do better than
linux I can't see why they would use NetBSD rather than linux (and linux
is better than NetBSD on a fair number of points already).

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--