Re: HEADSUP: ibcs2 and svr4 compat headed for history

From: Robert Watson (rwatson_at_freebsd.org)
Date: 06/27/04

  • Next message: David O'Brien: "Re: AMD64 vs i386 for FreeBSD" 
    Date: Sat, 26 Jun 2004 18:31:20 -0400 (EDT)
To: Alex Keahan <alex@hightemplar.com>

    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@fledge.watson.org Principal Research Scientist, McAfee Research

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: David O'Brien: "Re: AMD64 vs i386 for FreeBSD"

    Relevant Pages

    • Re: Towards a responsible vulnerability process
      ... in tremendous improvements in developer education. ... But the best example we have of code that is nearly bug-free is the ... The very best developers create few bugs, ... learn after some number of unpleasant experiences. ...
      (NT-Bugtraq)
    • Re: Why has the Metrowerks sign been taken down?
      ... > decisions that need to be made - if every developer wrote up a bug on IB ... time you figure out you can't import menus with IB, ... to wait for Apple to add that feature in response to a feature request. ... reproducible bugs that never should have even been shipped. ...
      (comp.sys.mac.programmer.codewarrior)
    • Re: TDD: Test-Driven Design or Test-Driven Development?
      ... You are allowed to cause friction on USENET - that's what it's for. ... The TDD cycle is very good at preventing bugs, and making the few that slip ... > also be mandated that every developer should document ...
      (comp.object)
    • Re: Decompiler.NET reverse engineers your CLS compliant code
      ... > entire developer community reading this thread because they are interested ... >> speech over and over about how many bugs you've reported to other ... > library or part of the framework, we adapt our implementation to avoid it ...
      (microsoft.public.dotnet.languages.vb)
    • Re: Decompiler.NET reverse engineers your CLS compliant code
      ... entire developer community reading this thread because they are interested ... > speech over and over about how many bugs you've reported to other ... > there known bugs within the framework itself, ...
      (microsoft.public.dotnet.languages.vb)