Date: Sat, 9 Jan 2010 13:04:44 +0100 From: Ed Schouten <ed@80386.nl> To: arch@FreeBSD.org Subject: Replacing <utmp.h> with <utmpx.h> Message-ID: <20100109120444.GW64905@hoeg.nl>
next in thread | raw e-mail | index | archive | help
--AvHEjN7DoAM1hYpY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, Some of you probably know that the last couple of weeks I've been slowly working on an implementation of <utmpx.h> for FreeBSD: http://www.opengroup.org/onlinepubs/9699919799/basedefs/utmpx.h.html This interface has the following differences when compared to our existing `API' described in <utmp.h>: - It uses library functions to interact with the underlying storage, which means in theory one could use sockets, pigeons and what not to transmit the records, instead of being restricted to files on disk. - Instead of reserving various keywords to denote special messages (i.e. boot/shutdown time), it uses a field called ut_type, which is nice. - The role of ut_line is less important than it used to be. Instead of being used as an identifier of login sessions, this is now done using ut_id. This means you can perform user accounting of services that are not related to TTYs (e.g. FTP) by leaving ut_line blank. You can also store multiple records per TTY, which means using login(1) within a shell shouldn't clobber the existing accounting record. - Timestamps are represented as a struct timeval instead of an uint32_t, which means we gain microsecond precision. I'm not sure whether it's useful in practice, but it comes with the package. It also means we can make it work past 2038. My file format just stores the timestamps as an uint64_t holding the number of microseconds since 01-01-1970, which means it can go up to the year 586524. I'm planning on committing my utmpx implementation within a couple of weeks from now, so I thought I'd better send a message about it first, highlighting some of my design decisions. It would be nice if I could get most of our requirements in there, because I'd rather not change the API/file format too often. First of all, one of the biggest changes I'm going to make, is that I'm going to remove <utmp.h> entirely. Most operating systems try to implement both utmp and utmpx, but this is not possible in our case. Those operating systems already provide library functions to update utmp files, so they can internally convert it to utmpx. We don't, which means we'll get two databases with the same purpose, only leading to confusion for the programmer/user/system administrator. Second, the POSIX interface only standardizes the utmpx interface, but no functions to update wtmp or lastlog. After some thinking I came to the conclusion that this is not a problem for us. My implementation of pututxline() already updates all the log files properly, improving their consistency. I only added two non-standard functions which can be used by our own applications in the base system to perform lookups on the wtmp and lastlog databases, called setutxdb() and getutxuser(). I think Robert Watson made a remark about backward/forward compatibility of the file format. Even though my solution is not bullet-proof, I think it should be good enough in practice. The database holding the active sessions (originally called `utmp', now called `utx.active') is always discarded when rebooting the system. The entire log file (`wtmp' or `utx.log') includes a length for each entry, which means we can safely resize the records. The last login database (`lastlog' or `utx.lastlogin') provides no compatibility mechanisms, but this will not be an issue in practice, because of its low importance. The file format is equal on both big and little endian systems. Right now the utmpx records provide little additional information over the old format (user, line, host, pid, tv). I have incremented the size of the fields, which means we can store 32 byte usernames and TTY names. Hostnames are now 128 bytes. Various people mentioned they would like to see additional fields to be added, such as a local and remote IP address. Be sure to mention this to me as soon as possible, because then I can include it before committing it. Here are some links to useful files inside my SVN branch: - http://svn.freebsd.org/viewvc/base/user/ed/utmpx/include/utmpx.h?view=3Dm= arkup - http://svn.freebsd.org/viewvc/base/user/ed/utmpx/lib/libc/gen/getutxent.c= ?view=3Dmarkup - http://svn.freebsd.org/viewvc/base/user/ed/utmpx/lib/libc/gen/pututxline.= c?view=3Dmarkup - http://svn.freebsd.org/viewvc/base/user/ed/utmpx/lib/libc/gen/utxdb.c?vie= w=3Dmarkup - http://svn.freebsd.org/viewvc/base/user/ed/utmpx/lib/libc/gen/utxdb.h?vie= w=3Dmarkup I've also stored a copy of a formatted man page online: - http://80386.nl/pub/getutxent.txt I've requested a ports exp-run to see how big the impact is. Some initial testing shows the amount of ports that break is little, but does affect some high-profile ports. I'll see what I can do to make the transition as easy as possible. --=20 Ed Schouten <ed@80386.nl> WWW: http://80386.nl/ --AvHEjN7DoAM1hYpY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktIcNwACgkQ52SDGA2eCwWiEACff/N3Xma8NaP75vFeb8ovkOx5 M8EAnRE8+Q33s7MmwgRkmBLPPCHRT4I8 =pcL2 -----END PGP SIGNATURE----- --AvHEjN7DoAM1hYpY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100109120444.GW64905>