Date: Tue, 09 Dec 1997 11:28:50 +1030 From: Mike Smith <mike@smith.net.au> To: Eivind Eklund <perhaps@yes.no> Cc: Mike Smith <mike@smith.net.au>, dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: VM system info Message-ID: <199712090058.LAA06720@word.smith.net.au> In-Reply-To: Your message of "Tue, 09 Dec 1997 01:39:41 BST." <19971209013941.17444@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> [Mike Smith] > > [Eivind Eklund] > >> [Mike Smith] > >>> Would you buy it in /usr/share/misc/sysctl_nodes? I was thinking > >>> about that when I saved John's message... > >> > >> If extracted from the kernel source, I'd say it was OK. > > > > Extracting from kernel source (at build time) is quite obviously > > pointless. > > ? > > I'd say this give you a fairly recent snapshot of the available > IOCTLs; I certainly update my kernel more often that my manpages (and > much more often that /usr/share). Exactly. Now assume I go build a kernel for someone else. Or build a 2.2 release on a 3.x machine. The kernel build doesn't affect anything outside the build arena; changing this would be a fatal mistake. > I'd opt for it to be compiled as part of 'make world' instead, but > there are certainly some good points to doing it at the kernel build > tilme. If it was possible to automatically generate a supserset listing at 'world' time, that would be good. > <GENERAL RANT> > Any attempt at making things easier for the newcomers at a slight, > indirect expense to the people 'in the know' seems to be shouted down > immedately. Leanness of the kernel and the source tree seems to have > a small but vocal minority that shout down any documentation that > might actually be kept up to date. (Ref my attempt at finding some > tolerable way to provide inline documentation for kernel file use last > easter). > </GENERAL> I'm glad you made this a "general" rant; I'd have been *extremely* offended if you put me in that category. If I thought that there was an easy way to arrange pageable kernel data, I would be leaping and screaming about putting the above data in the kernel RBN. As it is, any alternative scheme that will serve as a stopgap for now and actually achieve the desired goal without requiring massive trampling of the kernel and major changes to the interface appeals. Hacking some gratuitous macro changes in as a quickie-fix just doesn't cut it. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712090058.LAA06720>