On Fri, 21 Sep 2001, Greg A. Woods wrote:

: Implementation of real-time synchronisation cannot be justified,

You don't need "real-time synchronization" (as in the Solaris update daemon)
if you implement a three-function device node.  Translate it at the file
operations level, and you have compatibility with nearly no overhead.  See
below.

: In the real world the number of wtmp/utmp frobbing programs is
: necessarily very small (since write access to those files requires
: special privileges).

: From an engineering standpoint the justification just isn't there.

Just because it has no affect on you doesn't mean that it does not affect
others.  There are many programs which make use of utmp/wtmp that are
third-party, and I'm using three of them at this very moment.  Whether or
not source is "available" is not relevant to whether binary compatibility is
needed, because not everyone can recompile everything on a whim.

: 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.

Now, if you'd come down off the flame-throwing pedestal for a moment, and
read what I have said about doing access-time conversion, you'll understand
why I proposed it that way.  I'm not in `some dream land', I assure you.

As I stated in my other mail (with To: is@netbsd.org), there is no userland
place in NetBSD where you can easily implement *seeking* of a file -- here,
an old-utmp "looking glass file" of the new-utmp data -- to arbitrary
positions.  You can have pipes that read and write, and have portalfs hand
over fd's to those pipes, but that's it.  No lseek().

So the choices we have are:

- implement an update daemon such as Solaris (involves tricky
  synchronization code, and really not worth it IMNSHO);

- implement a real userland fs layer that can cope with lseek(2) (and isn't
  a hack layer over the NFS protocol as in sharity-light);

- implement a device node that does the three necessary functions (read,
  write, seek).

The last option looks like the least work to me.

: > 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.

TNF is committed to backwards compatibility wherever it can be added with
relatively little overhead and effort.  And what I've proposed above fits
that definition.

Now, on the flip side, writing this kind of mail that borders on flame,
dismissing arguments based solely on singular experience as coming from
`some dream land' -- that *is* contradictory to TNF's aims, and certainly
counterproductive.  If, instead, you'd like to discuss the *technical*
implications of this, please feel free.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5.2 available on CD-ROM soon!  --  http://www.wasabisystems.com/