[ On Wednesday, August 22, 2001 at 23:34:13 (+0900), itojun@iijlab.net wrote: ]
> Subject: Re: utmp file format change 
>
> >> > Are there good reasons for keeping a binary format?
> 
> 	i was just wondering how many application we would need to
> 	rewrite/change (incl. thirdparty apps like kterm/xterm/whatever),
> 	and i thought we should minimize the change from the current file
> 	format - only the changes in these constants (which leads me to
> 	prefer openbsd approach).

If NetBSD were to implement the full SysV API for wtmp/utmp handling
then there'd be less worries about third party apps since they would
just use the API, and many will already have code to do so (though it
may need to be specially enabled).

       #include <utmp.h>

       struct utmp *getutent (void);

       struct utmp *getutid (const struct utmp *id);

       struct utmp *getutline (const struct utmp *line);

       struct utmp *pututline (const struct utmp *utmp);

       void setutent (void);

       void endutent (void);

       int utmpname (const char *file);

I had all of this stuff written at one point, using a new record format
of my own definition -- I'll try to find it.

The important thing is to improve the data format so that all the
necessary information is recorded (that's why my implementation used a
new layout for struct utmp).  The old V7 format (of which our current
*BSD format is an extension of), is pretty brain-dead and loses big for
doing any kind of real analysis on the data.  The SysV format (of which
the SysVr4 utmpx is an extension of), is MUCH better, though not yet
anywhere near perfect, and of course it includes fluf that for the
moment *BSD doesn't need (ut_id and RUN_LVL, for example).  One major
failing of *BSD and SysVr4's utmpx both is that they only include one
ut_host field -- there *really* needs to be a ut_haddr in addition!

The file format could be made to be text-based if desired, though there
are some advantages to binary, or at least fixed-length, records, such
as for what "last" does.  There's also the advantage that binary data of
this form is much smaller....  Obviously in this modern day of non-VAX
systems the data should probably be stored in network byte order if it's
going to be binary on the disk.

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