On Sep 23,  5:46pm, woods@weird.com (Greg A. Woods) wrote:
-- Subject: Re: utmpx.h

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

Pid is easy and might be useful. Who is responsible for writing out the
exit code? And how can that be done reliably?

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

Fine with that.

| > 	- the accessor routines are not re-entrant.
| 
| Yup -- but this is a problem for all SuSv2 compatible systems, so what?
| 
This is anot a major issue. There are other minor details, such as having
the strings being fixed length and non nul terminated.
| 
| > 	- 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).

Even if they change usernames to 32 characters?

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

Yes, someone else pointed that too.

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

Neither Posix, nor X/Open has picked on the api's IIRC. It is only SuSv2,
and it is not a well thought out api unfortunately.

christos