At the risk of needing a new pair of kevlar/asbestos long johns,
dare I step in here and point out that anything that scrozzles on utmp
directly (instead of making use of utmp routines) deserves the fate it
gets?

There is a point where we are going to be suffering from backward-
combatability (look it up).  We will need to deal with that when -- not
if -- it happens.

I will agree that to recompile the world is a ++pain_in_the_arse, and the
people on slow boxen have my extreme sympathy, especially given that
cross-tools don't exist for many of them.

But every now and again, stuff is going to have to be rebuilt.  I find
myself rebuilding my entire world probably about thrice to ten times
in a year just to stay current.

Implementing a libc abstraction would be a good first step, and will
probably fix a good deal of the programs out there, once they're re-
compiled (sticking point, I know, I know, but still...), seeing as
most of them (especially those using configure) can autoconfigure
to use getutmp and company.

This would be a very very VERY Good Thing.

We can only retain so much backward-compatibility before it becomes
baggage, at which point it will be necessary to take a very good look
at it and decide whether or not to keep said baggage.

I'm actually rather surprised that we DON'T have an API that deals
with it -- I could have sworn that we did.

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

# Date: Fri, 21 Sep 2001 14:26:06 -0400 (EDT)
# From: Greg A. Woods <woods@weird.com>
# Reply-To: NetBSD Userlevel Technical Discussion List
#     <tech-userlevel@netbsd.org>
# To: NetBSD Userlevel Technical Discussion List <tech-userlevel@netbsd.org>
# Subject: Re: utmp file format change
#
# [ 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>
#


				--*greywolf;
--
NetBSD: safe ports in a storm.