I think this is all making a mountain out of a molehill.  To me, the best
suggestion I have seen is the one which reflected keeping old utmp around
for deprecated backward compatibility, TO BE REMOVED IN A NEAR FUTURE
RELEASE, but building an API ({get,set,put,end}utent((utmp_cookie_t *)))
to be used immediately; this would give any third-party utmp-manglers
AT LEAST six months, if not more, to get their act together.

Any other process for doing this is going to be bloat.  We've already got
an amazing amount of bloat there as it is, what with retaining all the
backward compatibility to pre-1.0.  We must be the only OS on the face
of the planet to have an eleven-year backward-compatibility timespan!
This is insane.  I mean, yeah, it's a cool thing to be able to declare
that, but man, we're getting a little hefty around the midsection lately.

On Fri, 5 Oct 2001, Todd Vierling wrote:

# Date: Fri, 5 Oct 2001 10:26:16 -0400 (EDT)
# From: Todd Vierling <tv@wasabisystems.com>
# To: Simon J. Gerraty <sjg@crufty.net>
# Cc: tech-userlevel@netbsd.org
# Subject: Re: utmp file format change
#
# On Sat, 22 Sep 2001, Simon J. Gerraty wrote:
#
# : >A device node doing the translation is my best suggestion at this point, as
# : >it doesn't have the problems of Solaris's "update daemon":  it catches
# : >old-utmp accesses where they happen, and needs no "cleanup" procedure.
# :
# : Do you have an estimate on how much work this is?
#
# Eh, you're basically looking at a small bit of device code that holds a
# vnode to the new-utmp file, and has two small buffers exactly equal to the
# size of an old-utmp entry and new-utmp entry.  It's just a matter of
# translating records one at a time.
#
# Granted, a real userlevel fs abstraction would be more desirable....
#
# --
# -- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
# -- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/
#
#


				--*greywolf;
--
NetBSD: SIMMs Like Good Code.