Date: Sun, 21 Feb 1999 13:32:57 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Bruce Evans <bde@zeta.org.au> Cc: phk@critter.freebsd.dk, current@FreeBSD.ORG, dfr@FreeBSD.ORG, romanp@wuppy.rcs.ru Subject: Re: Problems with nfsstat and dynamic OID Message-ID: <Pine.BSF.4.05.9902211322320.82049-100000@herring.nlsystems.com> In-Reply-To: <199902211314.AAA08457@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Feb 1999, Bruce Evans wrote: > >>The old interface is the standard one (although the above code shows how > >>inconvenient it is). mountd uses it too. > > > >There is nothing "less standard" about sysctlbyname to my knowledge... > > sysctl() is in Linux (starting in 2.1.x), BSD4.4, NetBSD, OpenBSD, etc. > sysctlbyname() is in FreeBSD (starting in 2.2). > > Some of the Linux sysctl numbers are even binary compatible. However, > all Linux filesystem sysctls are incompatible, starting with the top-level > identifier being named CTL_FS instead of CTL_VFS. If more than just NFS was defining its own sysctl variables, I might be worried but as I found out when I did the original dynamic sysctl work, only NFS actually used the (IMHO) ugly mechanism for rewiring its oid number by putting a pointer to the oid in its struct vfsops. Since sysctlbyname exists and is obviously a better mechanism for reading the variable (based on code complexity), then why not use it? We maintain both nfsstat and mountd in our tree and I don't see anyone expecting to be able to run Net/OpenBSD versions of those utilities on FreeBSD. If people feel strongly that we should continue to support the old mechanism, I guess I could modify vfs_register to change the oid numbers. It doesn't really seem worth it to me though. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9902211322320.82049-100000>