From owner-freebsd-hackers Mon Jul 21 03:57:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA06578 for hackers-outgoing; Mon, 21 Jul 1997 03:57:19 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA06573 for ; Mon, 21 Jul 1997 03:57:15 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id UAA22881; Mon, 21 Jul 1997 20:26:42 +0930 (CST) From: Michael Smith Message-Id: <199707211056.UAA22881@genesis.atrad.adelaide.edu.au> Subject: Re: utmp/wtmp interface In-Reply-To: <199707211011.UAA00760@labs.usn.blaze.net.au> from David Nugent at "Jul 21, 97 08:10:59 pm" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Mon, 21 Jul 1997 20:26:41 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 [[