Re: HEADSUP: ibcs2 and svr4 compat headed for history

From: Robert Watson <rwatson_at_freebsd.org>
Date: Sun, 27 Jun 2004 11:23:44 -0400 (EDT)
On Sun, 27 Jun 2004, Cordula's Web wrote:

> I do use Maple V/Solaris x86 (but under CURRENT only in text mode) with
> the svr4 emulation. It was not really easy to find all libs and fiddle
> with the loader, but it works, at least on my copy. 
> 
> However, if the mere presence of svr4 in the 5.x kernel slows other
> important development down, then it is a good and valid reason to axe
> it.  I have other ways to run this and no more objections. 
> 
> Thanks for clarifying the reasons behind this decision. 

Well, I don't know if I would call what I wrote reasons behind this
decision, so much as a justification and context for intermittent removal
of functionality from the tree.  As I said, I don't really have an opinion
specifically on the svr4 compatibility code, as much as on how we
structure the project.  The primary complaint about the svr4 and ibcs2
code is that they are both large pieces of code undergoing minimal
"maintenance" -- that is to say, incremental bug fixing and cleanup by a
party willing to claim responsibility for the subsystem.  In contrast, we
have less frequently used subsystems which do see active maintenance (MAC
Framework being one), and there seems not to be too much discussion of
removing them.  So the key to having functionality live on in the presence
of widespread change in the tree is having a willing and credible
maintainer; if you know of someone willing to do this, that would probably
make a big difference :-).  While the axes in the project may well have
their way on this one, it's worth keeping in mind that there will be more
discussion of it than just by said axes.  The release engineering team,
for example, will certainly have something to say on the topic. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research
Received on Sun Jun 27 2004 - 13:23:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:59 UTC