Re: HEADSUP: ibcs2 and svr4 compat headed for history

On Sat, 26 Jun 2004, Alex Keahan wrote:

> > The kernel's internal interfaces change; security bugs are discovered.
> > Someone has to keep the code up to date, and the people who end up doing
> > the work are *not* the people who advocate keeping the code around.
> 
> That's a slippery slope and you don't want to go there. 
> 
> Maintenance of old code is the price you have to pay when you write new
> code.  That includes kernel interfaces and security bugs. 

Actually, Tim is not referring to security or other bugs that results from
changes to the remainder of the code, rather, flaws that have existed in
the svr4 code since inception.  The svr4 code was apparently not written
with an awareness of current concerns about buffer overflows, integer
overflows, etc.  Tim has invested a substantial amount of energy in trying
to fix these issues in the svr4 code, but the reality is that regardless
of any "bitrot" resulting from API changes inside the kernel, the svr4
code has serious bugs and issues, and no one owns the code.  Many people
would rather see Tim optimizing IPC performance, fixing bugs in mainstream
code, finishing his multi-byte character support, etc.

I don't really have a strong opinion on the removal of this code, since I
don't use it or know anyone uses it, but I will say I agree with Tim's
general observation that there are substantial volumes of code in the
FreeBSD kernel that do impact our ability to introduce other new features,
adapt to new platforms, perform performance optimization, etc.  Any
individual bit of such code can be maintained incrementally at low cost
(and for us, cost means specifically volunteer developer time), but that
as a whole, it does have a "weighing down"  effect. 

The classic example of this is in our SMP work.  One of the big
impediments to forward progress in locking is that we do have a lot of
"legacy" pieces of the system without owners who can perform the locking
work.  In the immediate short term we're going to hit a situation where we
have to pick if we do or don't want Giant running over the network stack
by default.  If we opt to have it off by default, mainstream functionality
will operate much faster, but subsystems unable to run without Giant will
be broken.  If we leave Giant on, then everything runs, but the mainstream
bits will run slower.  It's a boot-time selection right now, and works
well in my development environment; the existence of the selection
recognizes the trade-off.  Eventually, I'm going to get to every piece of
the stack and lock it down, but if the existence of edge case code that's
not widely used causes us to defer permitting more mainstream code running
faster, that's a trade-off we have to consider carefully.

As with any commercial development organization, we have to make
trade-offs about how we invest our resources -- it's a little harder, in
fact, because I can't just tell people to work on things they don't want
to work on.  I have to convince them :-).  This means that a slight
pressure to remove under-maintained and unused or largely unused
components will always exist, and sometimes doing so will make the overall
work of the project much easier (or even possible). 

Someone will always disagree with the removal of any functionality or
service; the hard thing to tell from a developer perspective is whether
there are one or two people using it, or thousands.  Sometimes someone
will propose removing something and be overruled pretty quickly; other
times, not so.

The short answer, btw, is that if you (or someone you know) really cares
about svr4, you'll need to identify someone to maintain it and bring it
along.  It might be an existing FreeBSD developer, or someone new.  But it
has to be someone who can show sustained interest in making it happen. 

> I just hope the removal of IBCS2 is not a political decision to get back
> at SCO for their predatory legal tactics. 

I hardly think we'd be doing any damage to SCO by removing ABI
compatibility with their system, and so any attempt to do so by this means
would be pretty naive. :-)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research