[ On Friday, September 21, 2001 at 22:44:13 (-0400), Todd Vierling wrote: ]
> Subject: Re: utmp file format change 
>
> On Fri, 21 Sep 2001, Greg A. Woods wrote:
> 
> : 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.

I probably make more use out of wtmp and utmp than the majority of
NetBSD users -- I've even hacked a bit on xterm to try and get it to
work properly and more safely to show.  I actually do session accounting
on some systems, not that the results are of any longer of any monetary
importance to me -- I still just like having them.  I have managed
switch-overs from SysVr3 utmp to SysVr4 utmpx, as well as from from
SysVr3 to SunOS-4, in the past though in places where session accounting
did have a wee bit more importance though (i.e. it paid the bills).

Perhaps that's why I really do know exactly how to deal with a change in
wtmp/utmp format, and what effect it will have, and what "costs" it will
have.  That's why I know from direct experience that there is no
engineering justification for even contemplating writing kernel code for
this kind of thing.  I apologize for not making my past experience with
and knowledge of this particular issue more abundantly clear the first
time around, but I thought maybe I had already done so in a past thread
discussing this same issue.


One important idea that's not been raised again this time around is the
potential to have be a short migration period, say one minor release,
where the libc code provides a run-time switch to handle either old or
new format files.  That should give you what, 6 months to recompile
third-party software?  The code to handle old-format files could even
sit in the source tree until the next major release, just #ifdef'ed out.

I don't know if the effort that would be required to offer this degree
of compatability is really worth it or not.  So far we've not yet (as
far as I can remember) heard from anyone else who runs 'ac' or similar
on a regular basis and who uses third-party utmp/wtmp-frobbing programs
that would be hard to update during an OS upgrade.


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

"Many" != 3.  Which three?

Better yet, how many of those three are _not_ in pkgsrc?

How many wtmp/utmp frobbing programs that can run on any NetBSD are
there total which are not in pgksrc?

>  Whether or
> not source is "available" is not relevant to whether binary compatibility is
> needed, because not everyone can recompile everything on a whim.

Like I said, nobody need recompile third-party code instantly -- the
emulation hooks can be used to deal with the issue

However it's beginning to look as if emulation hooks are only of use if
there's critical third-party code which really cannot ever be
recompiled.  I expect in a volunteer project that such support for such
a tiny fraction of users will have to come from those who really need
it.

> 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().

I'm not talking about doing those sorts of things in some file
abstraction layer -- I'm talking about dealing with the data records in
userland directly.  No kernel frobbing necessary. No portalfs hooks
necessary.

> So the choices we have are:
> 
> - implement an update daemon such as Solaris (involves tricky
>   synchronization code, and really not worth it IMNSHO);

That's only necessary if you go the route of using the emulation code
and you end up having some old-format file that has to be kept in sync
with the live system data in the new format.  This is so unlikely in any
significant number of sites that it's probably best to leave it to those
who really need it (and freeware code already exists to do this, albiet
without yet any handling for whatever format the new NetBSD one might be).

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

The last two are still not justified in any way whatosever from a
real-world engineering standpoint.

You have the source, as do all third-party NetBSD vendors who might have
more vested interests in maintaining stricter backwards compatability
for their paying customers.

Adding kernel frobbing is just asking for trouble.  This data never
needs to get any closer to the kernel than it already does through
read() & write().

The least work, and the only justifiable work, for managing a conversion
of this kind of data is to give a short period of time where run-time
support is offered for optional handling of either the old format or the
new format (with the default to use on the new format -- most people
won't even notice).  However even before we go this far we should
probably hear from at least someone who use session accounting records
and who has third-party software that might not be easy to update during
a system OS upgrade.

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