From owner-freebsd-hackers Wed May 14 07:30:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA11443 for hackers-outgoing; Wed, 14 May 1997 07:30:26 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA11428 for ; Wed, 14 May 1997 07:30:19 -0700 (PDT) Received: from labs.usn.blaze.net.au (local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.5/8.8.5) with ESMTP id AAA00677; Thu, 15 May 1997 00:27:34 +1000 (EST) Message-Id: <199705141427.AAA00677@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: hackers@freebsd.org, David Dawes Subject: Re: xdm in /usr/X11R6/etc/rc.d problem In-reply-to: Your message of "Wed, 14 May 1997 12:38:17 +0200." <19970514123817.KP49302@uriah.heep.sax.de> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 May 1997 00:27:33 +1000 From: David Nugent Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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/