Date: Thu, 15 May 1997 00:27:33 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: hackers@freebsd.org, David Dawes <dawes@rf900.physics.usyd.edu.au> Subject: Re: xdm in /usr/X11R6/etc/rc.d problem Message-ID: <199705141427.AAA00677@labs.usn.blaze.net.au> In-Reply-To: Your message of "Wed, 14 May 1997 12:38:17 %2B0200." <19970514123817.KP49302@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> If you do however, it might be worth the while to do the deed. David
> (N.), could you take it?
Yes, I've been working on it.
Lastlogin (part of the 'utmp' package) was relative easy. Defining
an extensible format for utmp/wtmp wasn't such a pushover,
unfortunately, once I had thought through all of the issues.
If I post the code I'm working on to you for comment, is anyone
interested in looking at it? Bear in mind that there's a time-frame
to be kept with Xfree 3.3's impending release - we can either miss
this completely and hope that there's another release prior FreeBSD
3.0 (possible?) or we can finish the api now, so comments should be
fast. [If I had started this a couple of weeks ago when it first
came up, there wouldn't be such a hurry, but I had other things to
do then. :-(]. If there are major objections to the approach I've
taken, then we'll just hold off and not worry about Xfree 3.3, and
resolve it in our own good time.
While the modules themselves are BSD in nature, I also want to put
in code to handle other OS's, so they can be submitted to the
various OS groups and incorporated without them having to do
terribly much. It'd be nice having a reasonably uniform OS-independant
interface to wtmp/utmp at least between freely available operating
systems. I know it would save many headaches. Until accepted by
the various OS's, the code could probably be used as is with the
relevant #defines as a generic utmp/wtmp interface anyway (until
those OS's start toying with the format of the underlying files,
at any rate :-)).
The problem I'm running into is deciding how to do an "extensible"
interface to utmp/wtmp. First, the actual utmp/wtmp structures
(I actually use xutmp to help avoid name collision problems, and
utmpx seems already to be in use in some environments) use the usual
fields present in a utmp struct, but they are NUL terminated strings
(char*) rather than fixed sized arrays - the API does all of the
packing unpacking as appropriate, including FreeBSD's usual hostname
shortening currently done by login(1), so that parts of the hostname
fields don't get blown away.
But if someone wants to add extra data to each record, I have a
struct xutmpinfo*, which is a ptr to an array containing additional
information. Or it can be a linked list (with an addition field
for a 'next' ptr):
struct xutmpinfo {
int type;
int len;
void *data;
};
With utmp, the record size can actually be *runtime* determined
(but to begin with, no additional information is catered for, so
it is backwards compatible until we can sort out all of the source
tree and the ports that use utmp/wtmp directly), and I thought
about the possibility of putting 'tagged' data after each record.
The actual record size is contained in the ut_time field in the
first slot, which is currently unusued (or as far as I can
determine it is, since ttyslot() starts at 1, and 0 means "none
present". I don't think it is used for anything else - correct me
if I am wrong).
wtmp, however, is another thing. We can't easily change the
record size between reboots, because it just grows, and (right
now at least) everything assumes a uniform record size. Adding
more data to each record and we end up throwing out past
records, which is imho unacceptible, and allocating lots of
"spare" space to each record is an equally gross solution.
Ultimately, the extensions in wtmp can be added if the format of
the actual file is changed, unlike utmp, where it doesn't really
need to - not right now. Right now we can just define the API and
work to have everything else keep their hands directly off it.
I think the best format for wtmp will be a standard text line-feed
delimited file only, and in fact this will be considerably *smaller*
than the present wtmp because the current fixed length records waste
a lot of space. Things like last(1) will have to be able to cast
through that backwards which is not so easy to do with variable length
records, but the API will even have an interface that supports that
(with buffering as well), so they won't have to worry about it.
Now, if you've followed me so far, well and good. :) The problem
I'm having related to saving and retrieval of this 'tagged data'
for utmp. Perhaps I can delay the decision as to how this is done
until later, but I think in order to prevent this becoming bit-rot
because it hasn't been thought out properly, it needs to be
discussed. Should I post the code, or upload it to freefall for
everyone to fetch? It is not yet quite complete, but should be
done within the next day or so. Suggestions, comments and bugfixes
on it would be most welcome.
FWIW, most of the difficulties relate to memory management when
/reading/ the tagged data for utmp. IMHO the interface isn't very
clean, so perhaps someone with a fresh viewpoint might be able to
suggest a better way to handle it.
Regards,
David
David Nugent - Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet
davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705141427.AAA00677>