Date: Sat, 13 Oct 2001 12:51:51 +0400 From: Yar Tikhiy <yar@freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: hackers@freebsd.org, doc@freebsd.org Subject: Re: utmp(5) manpage revised Message-ID: <20011013125151.A93286@snark.rinet.ru> In-Reply-To: <3BC736E5.2AF183F4@mindspring.com> References: <20011011170226.A2162@snark.rinet.ru> <3BC736E5.2AF183F4@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you Terry for your comments! On Fri, Oct 12, 2001 at 11:31:01AM -0700, Terry Lambert wrote: > Yar Tikhiy wrote: > > > > The current utmp(5) manpage language (not markup) > > has a number of drawbacks and errors: > > > > o There is no information for programmers on the actual structure > > of the files the page describes. > > It is opaque. You are not supposed to access it directly, you > are supposed to use library routines. You could make the same > argument about "db" files... There are no library functions to manage the lastlog file yet, so at least this file's structure should be documented. Why not to stay consistent and document the two other files granted that their structure can be described in a sentence or two? > > o The C structure members aren't described. > > "" The C data structures aren't opaque that much either. The lastlog file is still managed directly, and the login(3) function takes a pointer to "struct utmp". > > o It describes in a wrong way how a user's logout is recorded to wtmp. > > I'm not sure that that's not an implementation detail that > should be reomved from the man page entirely, but what you've > done is equally valid. No it shouldn't. The authors of applications similar to SSH or telnetd need to know how to record user logouts. Of course, nobody is likely to start an alternative network terminal access project within the next few years, but... :-) > > Here's a patch addressing all the issues. Review it please. > > I'm not sure that the structure should be documented, as it > will encourage people to access the data directly. The point > of having them access it through library routines is that it's > possible to replace the implementation by replacing the libc.so > on a system, and have software continue to function. Or, it's > possible to install binaries that use libc.so on a system with > a different underlying implementaiton, and have them "just work" > for commercial vendors. FreeBSD is an open system, so IMHO people would be better discouraged of accessing the files directly by a paragraph in the manpage, which reads: "Don't do it, or this or that trouble will happen because of the following reason...". -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011013125151.A93286>