[ On Friday, September 21, 2001 at 11:02:02 (-0400), Todd Vierling wrote: ]
> Subject: Re: utmp file format change 
>
> It damn well is.  Because all BSD-utmp/wtmp based code doesn't have a libc
> abstraction, it is a *must* for us to have backwards compatibility.

I think you're completely ignoring real-world requirements for utmp/wtmp
funcationality and instead dreaming of some perfect world.

In the real world all it takes is one reboot to break the link between
an old wtmp/utmp format and a new wtmp/utmp format.

The existing binary emulation features provide more than all of the
necessary capabilities to maintain backwards compatability for
non-source program (or critical programs that cannot be recompiled right
away).

Implementation of real-time synchronisation cannot be justified,
especially since all system tools will necessarily already use the new
format following an upgrade.

In the real world the number of wtmp/utmp frobbing programs is
necessarily very small (since write access to those files requires
special privileges).  You're talking about doing kernel hacking like
none before just to support a very very very tiny fraction of users who
have a very very very tiny number of programs that could ever need such
support.  From an engineering standpoint the justification just isn't
there.

> Note that this need not necessarily be based on some `background daemon'.  A
> special device node with in-kernel emulation would also work; such a device
> would be relatively simple to implement.  It need only emulate read/write
> (struct translation) and seek (fixing offsets to their proper locations).

Now you're really off in some dream land.  We're talking here about data
that originates in userland and is only ever used in userland.

Why would anyone ever even dream of using the kernel to do any
conversion?  That would be the kind of system magic I'd expect only from
a single-user system.

> Not everyone can afford the overhead of "recompile everything" with a major
> release update.  And yes, backwards binary compatibility is one of TNP/TNF's
> primary stated goals.

Backwards binary compatability is a very fine thing to have for object
and executable code.

Taking such an idea to the N'th degree and forcing everything under the
sun to remain backwards comaptible is a very stupid and counter-
productive goal for an open source system to follow, and indeed one that
is apparently self-contradictory to _all_ of the other goals of The
NetBSD Foundation.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>