From owner-freebsd-arch Mon Jul 17 4:56:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from avon.wire.net.au (avon.wire.net.au [203.36.3.8]) by hub.freebsd.org (Postfix) with ESMTP id 6B9B737B8D7; Mon, 17 Jul 2000 04:56:49 -0700 (PDT) (envelope-from davidn@blaze.net.au) Received: from mobile.usn.blaze.net.au (mobile.usn.blaze.net.au [203.17.53.104]) by avon.wire.net.au (8.9.3/8.9.3) with ESMTP id VAA79628; Mon, 17 Jul 2000 21:56:43 +1000 (EST) (envelope-from davidn@blaze.net.au) Date: Sun, 16 Jul 2000 15:32:00 +1000 (EST) From: David Nugent X-Sender: davidn@mobile.mel.ausisp.net Reply-To: davidn@blaze.net.au To: Hajimu UMEMOTO Cc: cvs-committers@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: cvs commit: src/lib/libutil realhostname.c In-Reply-To: <200007141808.LAA07166@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 14 Jul 2000, Hajimu UMEMOTO wrote: > I have a grudge against the shortage of UT_HOSTSIZE. I have a grudge against the only legitmate uses of it; the utmp/wtmp formats. I had a go at fixing it once, but there did not seem a great deal of interest other than minor feedback. It's a difficult matter since fiddling with this messes with fringe portability and defacto BSD practices and standards (not that there really are any over a wider range of UNIXen, which is the real problem). Raw space savings in wtmp by use of a variable length, even text format is surprisingly large, and encapsulating it behind a standard API hides it enough that we should not need to worry about the physical storage mechanism, be it a berkeley db, flat text file, fix or variable length flat record, ldap directory or an sql database. nsswitch.conf might provide a gateway there (is anyone still working on nsswitch for FreeBSD these days?) Considering this is one of the few issues that gets in the way of expanding namespace on UNIX systems (capability of handling a full kerberos name.user@realm or ldap dn cn=davidn,dc=freebsd,dc=org are good examples), I think finally resolving this means that the limitations of UT_*SIZE are well on the way to just going away. The use of these macros elsewhere is - or at least used to be - a conveniently reliable limit. The kernel does impost a limit, but changing that would not be too difficult. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message