Date: Tue, 22 Jul 1997 00:42:38 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface Message-ID: <199707211442.AAA00370@labs.usn.blaze.net.au> In-Reply-To: Your message of "Mon, 21 Jul 1997 20:26:41 %2B0930." <199707211056.UAA22881@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's all there. What's missing? > > Uhm, some idea of what you're heading towards. I misread the lastlog.3 > manpage and misunderstood how much of it had been updated too. All that's different is a standardised API. In fact, this goes for all of the modules. Nothing has (yet) changed about any of the file formats - which a "suggested" alternate implementation for wtmp is there (#defined out), and utmp has become a runtime re-sizeable fixed record file, by default, these files use precisely the same format that they currently use. What I am attempting to do is to define an API to access these files, not radically change the format of the files overnight. That can come later, AFTER things use the API rather than use the files directly. There *is* provision for "additional" information to be added, and for utmp this is fairly easy using a slight variation of the current format (by enlarging each record, and the record size is determined at runtime rather than being a sizeof anything), and for wtmp would definitely require a change in format. Personally, I prever a text-based format with extensions in keyword=data style or something similar. You can deal with that in any language - even /bin/sh - with very little loss in performance. The idea is not to change the format of the files immediately, but to first define an API to access them so that it allows the format to be changed at whim later, without breaking compatibility with code that uses the API, both source AND binary compatibility, and old data retained and usable ad infinitum. We can at last kiss goodbye to the problems with XFree and other things that access utmp/wtmp directly. > Fair enough. The point I was making was that the legacy format Actually, it isn't really "legacy" - IIRC wtmp/utmp are fairly recent additions to BSD and utmp/wtmp implementations vary widely between systems already, so one more variation is no big deal. :-) I'm hoping that other OS's may adopt the same approach and hide their implementation somewhere in some system library, but I'm not about to hold my breath. :-) Still, it is the idea that counts. > > Could you explain that further? What is a "self-describing format"? > > A file format which contains meta-data describing the layout of the > file. Eg. at the head of the file, start with a record containing > the length of records in the file, followed by field, length tuples > describing the type and length of each of the fields in a record. Yuck. This is overkill. The idea behind the API is to have a library to access and update the database - noone should care beyond that what format the files actually use. This approach would seem to make a simple thing complex, and even encourage other software to bypass the API, which is not the idea at all. > Parsing this is very straightforward, as is using it to obtain the > fields you want. You can add new fields to the file, change the size > of fields, etc. without ever breaking binary compatability again. But you have broken compatibility. You've just thrown out all of your existing data. It also assumes fixed length fields which, in a logfile that is assumed to grow forever, is inappropriate. > Because records in the file are fixed in size, you can treat it as a > random-access file too. This is fine for utmp, but not wtmp. wtmp *needs* to be in variable length format. > > > static char sbuf[sizeof(pl) * 2]; > > > > Could you be a little more specific than "pretty bad"? > > I was repeating myself; sorry, ref. the static buffer. Ok. The "either" threw me, thinking you were discussing two different things: > > > Using a static buffer here isn't so great either. It's going to give > > > the threaded version cooties by default. 8) ~ > > These calls are not intended to be reentrant. > > Call it a matter of principle. 8) I realise that the alternative is a > little more work. Absolutely it is, and the penalty is paid by the non-threaded version, and it makes the code more complex then it need be in any case. The point is whether there is any benefit in making it thread-safe. :-) 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?199707211442.AAA00370>