Date: Mon, 21 Jul 1997 20:26:41 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: davidn@labs.usn.blaze.net.au (David Nugent) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface Message-ID: <199707211056.UAA22881@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707211011.UAA00760@labs.usn.blaze.net.au> from David Nugent at "Jul 21, 97 08:10:59 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
David Nugent stands accused of saying:
> Thanks for the feedback.
>
> > Hmm. "More documentation" 8)
>
> 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.
> > Seriously; I think that perhaps going in a similar direction to the
> > /etc/passwd approach might be good; write the 'old-format' files
> > when generating the records, but use an improved binary format under a
> > new (but related) filename when accessing it from the library.
>
> IMHO, this idea sucks. wtmp files on real systems get large enough
> already without doing it twice. :-(
... so rotate and compress them. This is a management issue; if you care
about the information, keep it. If not, discard it.
> It isn't too hard to modify
> legacy code here, and if you looked at the proposed new wtmp.h,
> you'll find it'll spit out compile warnings (maybe should be error?)
> for any file that includes it unless it defines a macro first. I'm
> not certain that this is *the* way to go, though, but I can't think
> of anything better.
Fair enough. The point I was making was that the legacy format, or
anything vaguely resembing it, is no longer really adequate. If you're
not afraid of completely abandoning backwards binary compatability, then
sure, just go the whole hog with a new format.
> > In particular, a self-describing format for something like utmp/wtmp
> > would be very sexy.
>
> 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.
For utmp, you might do :
0x0000 0x00000100 # 256-byte records
0x0004 0x00000001 # username
0x0008 0x00000020 # 32 bytes
0x000c 0x00000002 # login time
0x0010 0x00000004 # 4 bytes
0x0014 0x00000003 # source host IP
0x0018 0x00000004 # 4 bytes
0x001c 0x00000004 # source hostname
0x0020 0x00000080 # 128 bytes
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.
Because records in the file are fixed in size, you can treat it as a
random-access file too.
> > This fragment is pretty bad.
> >
> > 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.
> > 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. There are similar 'problems'
> with all of the get{pw,gr}*() routines, for example. Calling any of these
> functions from separate threads is something you just don't do, and for
> the life of me I can't think of a single reason why you'd ever need to
> in lastlog's case. :)
Call it a matter of principle. 8) I realise that the alternative is a
little more work.
> The alternative is to get into memory allocation, along with all the
> penalties in runtime and resource use, not to mention bloat.
*shrug* I don't think the penalties are really that bad, but it's not
something I'd fight over.
> David
--
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707211056.UAA22881>