[ On Sunday, September 23, 2001 at 16:05:09 (-0400), Christos Zoulas wrote: ]
> Subject: utmpx.h
>
> I've been thinking about the utmpx thing, and it seems to me that going
> to an svr4-like utmpx and and functions might not be the most suitable
> thing for us:
> 
> 	- there are fields that we don't need/don't have (run levels,
> 	  entry type, exit codes, pid)

Exit codes and PIDs are VERY good (xref to process accounting, check for
status, etc.).  I've missed both of these every time I've migrated a
system with session accounting from SysV to *BSD.

Indeed run levels are mostly irrelevant (though not 100% -- they can be
adapted to the run states BSD init has) and could be simply set to a
common value if desired.

> 	- the accessor routines are not re-entrant.

Yup -- but this is a problem for all SuSv2 compatible systems, so what?

I suspect if industry consensus is that a re-entrant API is necessary
then one will be defined and published and NetBSD can participate in
this process if/when it happens, or even lead the call....

> 	- they still expose the guts of the structures so they might
> 	  need utmpxx in the future.

Not for SuSv2 compatibility -- the listed fields are only the "required"
ones and additional ones (such as ut_host_addr) are allowed; and of
course the on-disk format isn't specified either so it can also be made
extensible too (which would be the only possible sensible way to do it
anyway).

> #define	_PATH_UTMPX	"/var/run/utmpx"
> #define	_PATH_WTMPX	"/var/log/wtmpx"

These names (i.e. the basenames) are a really bad idea if you're not
making them 100% compatible with ATT SysVr4....


I think a standards-compatible API is mandatory, regardless of whatever
might have to happen in the future to support some re-entrant API, as is
an extensible, architecture-indpendent, on-disk format.

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