Date: Mon, 19 Oct 1998 18:05:31 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: chuckr@mat.net (Chuck Robey) Cc: mike@smith.net.au, tlambert@primenet.com, andyf@speednet.com.au, freebsd-chat@FreeBSD.ORG Subject: Re: mount flags Message-ID: <199810191805.LAA29006@usr02.primenet.com> In-Reply-To: <Pine.BSF.4.05.9810182016460.348-100000@picnic.mat.net> from "Chuck Robey" at Oct 18, 98 08:32:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> True. I thought the string comparison idea silly, and didn't make the > argument well enough. Without trying to be cute or sarcastic or > anything, can I ask you to break down the phrase "VFS type numbers cast > in stone" as something more obviously good or evil? I can. The numbers that represent the FS's were their index into a list of statically configured per FS structures, including, among other information, their string name. The problem with this is that zero is taken (MOUNT_NONE), and that MOUNT_MAXTYPE is untrustworthy in the face of loadable modules. This basically means that the number would have to be disconeected from the index to allow arbitrary module loading. This is possible, but that engenders a new problem: when I add a new FS type to the system, what non-index number can I give it, such that I don't collide with any other FS anyone may, in the future, add to the system? The use of manifest constants in identifying VFS stacking layers is precisely tantamount to the assignment of major and minor numbers to devices: there is a strong requirement for a central namespace management authority. > The point, tho, is that you seem to imply that the manifest constants > used to ID a VFS have to have something to do with loading order. No, they have something to do with declaration order. And even though this can be spackled around, the issue of requiring a central authority to arbitrate the numbers can't be fixed. You can't modify the contents of the INITMOUNTNAMES string array in an already compiled program to reflect the addition of elements by the existance of one or more new VFS stacking layer types. > Is making it depend on an initially assigned number somehow evil? Yes. It implies a central management of initially assigned numbers. > Why can't I just specify that some constant, oh, 69, means nfsv3? Because you aren't the central authority, and so if you want to create a stacking layer, you have to go to that authority, with your hat in your hand, and ask for a number. 8-). > Heck, with names, do I mean "NFS" or "nfs"? At least with a number, > I've got some header file that stands as a registry. Making me do it > via string comparison doesn't sound incredibly useful or flexible. > > We do all our devices that way, right? (We do until DEVFS, anyways, > which may well mean forever, since there is still too little agreement > on even how that's to work). Right. And that is bad. > I'm glad I took this to chat, I can get away with one more argument > without really wearing away patience (I hope). I _really_ like what you > said about having both interfaces, that's *exactly* what I want to > propose to bde when he finally gets back to me. He's done most of > changes, so he's the one I have to talk to on it, but your comment is > encouraging. I _really_ dislike supporting the legacy interface, unless you are willing to forego access to all new VFS layers in order to use it, in which case, I'd grudgingly allow you to aim at your foot, but you should have to define some manifest constant before you are allowed to aim through the contents of a system header file, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810191805.LAA29006>