Date: Tue, 7 Jan 1997 01:54:48 +1100 From: davidn@unique.usn.blaze.net.au (David Nugent) To: hsu@clinet.fi (Heikki Suonsivu) Cc: phk@critter.dk.tfs.com (Poul-Henning Kamp), freebsd-current@freebsd.org Subject: Re: utmp changes Message-ID: <Mutt.19970107015448.davidn@labs.blaze.net.au> In-Reply-To: <199701061401.QAA21728@cantina.clinet.fi>; from Heikki Suonsivu on Jan 6, 1997 16:01:44 %2B0200 References: <18569.852321999@critter.dk.tfs.com> <199701061401.QAA21728@cantina.clinet.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
Heikki Suonsivu writes: > From: Poul-Henning Kamp <phk@critter.dk.tfs.com> > >but this is what I conceive as changing. The big thing is I'd like to fix > >the size of the utmp structure once and for all, and define the reserved > >area as must-be-zero so we don't get in the mess we just got in ever again. :- > > I would rather see variable-length records, it would save space and it is > the only way to be sure it will be enough for quite some time. It would be > more difficult to parse, but most of that can be hidden into a library. I definitely agree with variable length, but "difficult to parse" - not necessarily. FWIW, the accounting log file on our ISP box, a large part of which consolidates utmp data, uses a variable length newline delimited *text* record format and an accompanying db index for fast lookup. Two years and seven months of accounting data with 10 (now 16) dialin lines and the file is still only ~3.5mb (the index is somewhat bigger, but that's a different story :-)). Easily parsable in C, Perl, tcl - hell, even shell script if you're desperate. And given that all but the time field is text anyway... It would also solve the hostname/ip kludge login does, as well as offer easier transition to IPv6, addition of new fields and so on - all of which can happen transparently and be added ad hoc without any need to 'upgrade' a thing. Records with new fields are just appended as is, and anything that uses the field ignores what it doesn't know about so long as the existing fields aren't touched. It can be indexed anyway you like, fed directly in raw format to an SQL engine or any database you please. A big win. utmp is a different kettle. I can't see it being anything but a fixed record field without losing significantly. Either that, or the "ttyslot" idea needs to be revisited. As you say, this can all be 'hidden' from anything that doesn't care about the format (ie. almost everything that creates or updates these files) by the library interface. Regards, 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?Mutt.19970107015448.davidn>