Date: Tue, 22 Jul 1997 13:27:12 +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: <199707220357.NAA26773@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707211442.AAA00370@labs.usn.blaze.net.au> from David Nugent at "Jul 22, 97 00:42:38 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707220357.NAA26773>