[ On Friday, September 21, 2001 at 01:12:12 (-0400), Todd Vierling wrote: ]
> Subject: Re: utmp file format change 
>
> You might want to look at the Single Unix Specification -- it explicitly
> documents <utmpx.h>

Ah!  I didn't know that...

Strange they went with getutx(3) when the only thing they took from the
extended structure was ut_tv (instead of ut_time), and that they didn't
at least define ut_host, which was one of the primary motivators for
creating a new utmp format in the first place....

Conveniently SuSv2 allows the structure to be extended arbitrarily too.

Too bad they don't define the SysVr4 utmpxname() interface.  I still
don't understand why standards committees remove stuff like this.  A
database name can be a name in any namespace -- it doesn't have to be a
filesystem pathname.

> and its #define UTMP_FILE.

I can't find UTMP_FILE with the online SuSv2 search engine....

The only place I can find UTMP_FILE defined is in the SysVr4.2 utmp(4)
manual page and of course UTMPX_FILE is in utmpx(4).

>  The SUSv2 spec doesn't give
> details on how to use utmpx separately from wtmpx, but such usage can be
> copied from Solaris as "the" reference implementation.

I'm not so sure the Solaris solution is anywhere near ideal.  It has
numerous twisted bass-ackwards quirks due to their insane desire to give
100% backward binary run-time compatabilty of the on-disk data.

It thought the general consensus for NetBSD was to break free with a
properly defined new format and a compatible getut[x]*() API.

Luckily SuSv2 says nothing about the on-diskt format.

> If we also implement the SYSV <utmp.h>, great, but we definitely should
> implement the <utmpx.h> API since it has been documented, and is widely
> used.

I agree.  If I can find the code I once had for getut(3) it should be
quite easy to extend it into getutx(3), and further...

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