From owner-freebsd-current Fri Jun 28 9:21:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8692A37B406; Fri, 28 Jun 2002 09:21:20 -0700 (PDT) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69DD643E09; Fri, 28 Jun 2002 09:21:19 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g5SGLBHP145134; Fri, 28 Jun 2002 12:21:11 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020628110244.A34627@bsd.develop.ferrari.local> References: <20020628110244.A34627@bsd.develop.ferrari.local> Date: Fri, 28 Jun 2002 12:21:10 -0400 To: Robert Drehmel , current@FreeBSD.ORG From: Garance A Drosihn Subject: Re: changing 'struct utmp' Cc: robert@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:02 AM +0200 6/28/02, Robert Drehmel wrote: >Hello. > >While trying to fix the bug described in a problem report about >'w -n', and finding out that it is somewhat broken*, I came to >the conclusion that our 'struct utmp' is too limiting. > >I would like to modernize it as follows: The present utmp is way too limiting. At the same time, it's a pain to "just change it in place". It is a database format, where every user of the database has intimate knowledge of the internal format. If you change the size of anything, then you have to be SURE to compile absolutely everything that looks at utmp, and recompile them all at the same time. And you have to make sure that none of them have built-in assumptions about the field sizes, or you will introduce bugs if you blindly recompile them. I think it's better to leave utmp as it is, and start work on a utmpx definition which is more standardized. Access to this new improved database should be through the endutxent, getutxent, getutxid, getutxline, pututxline, and setutxent routines. For awhile we should generate both utmp and utmpx files, so we can gradually convert programs over to using the standardized API. Once we're happy with that, we can pull the plug on the old utmp file & it's format. See also the standardized definition of utmpx.h. It would be very nice to see this in freebsd. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message