From owner-freebsd-hackers Mon Jul 21 20:57:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA03289 for hackers-outgoing; Mon, 21 Jul 1997 20:57:35 -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 UAA03284 for ; Mon, 21 Jul 1997 20:57:31 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA26773; Tue, 22 Jul 1997 13:27:13 +0930 (CST) From: Michael Smith Message-Id: <199707220357.NAA26773@genesis.atrad.adelaide.edu.au> Subject: Re: utmp/wtmp interface In-Reply-To: <199707211442.AAA00370@labs.usn.blaze.net.au> from David Nugent at "Jul 22, 97 00:42:38 am" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Tue, 22 Jul 1997 13:27:12 +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: > > > 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 Argh. Yes, I missed the #ifdef's. *blush* > What I am attempting to do is to define an API to access these > files, not radically change the format of the files overnight. Ok, going back to this. With the xutmpinfo struct; is the plan to only support one, or a colocated array of several terminated with one with xi_type set to XUT_NONE? [file format changes] > 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. Actually, I would have suggested a textual format, but I thought that the screams would be audible from here. If you think it's a goer, you have my absolute support. > 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 Understood. > 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. :-) Good question. Maybe save worrying about that until it needs to be? > 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 [[