Date: Sun, 18 Oct 1998 19:40:39 -0700 From: Mike Smith <mike@smith.net.au> To: Chuck Robey <chuckr@mat.net> Cc: Mike Smith <mike@smith.net.au>, Terry Lambert <tlambert@primenet.com>, Andy Farkas <andyf@speednet.com.au>, freebsd-chat@FreeBSD.ORG Subject: Re: mount flags Message-ID: <199810190240.TAA15643@dingo.cdrom.com> In-Reply-To: Your message of "Sun, 18 Oct 1998 20:32:15 EDT." <Pine.BSF.4.05.9810182016460.348-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, 18 Oct 1998, Mike Smith wrote: > > > > 1) there is no registry for what the mapping is between an fs type > > > and what string is used to ID it, and > > > > This is arguably a failure in the transition to the new interface; > > the constants should remain, and likewise the interface that used them > > should still accept them, even if it performs the transformation to the > > character string before passing it to the kernel. > > > > > 2) why is it that a string comparison is felt to be cleaner, in a world > > > so worried about buffer overruns? That part at least seems terribly > > > wrong. On top of that, the data is done via linker set ... seems to > > > be an abuse-trap. > > > > > > Why is this cleaner? > > > > Because it's arbitrarily extensible, and does away with having to have > > the VFS type numbers cast in stone. If you wonder why having manifest > > VFS constants sucks, consider the current mess involving loadable VFS > > modules. What value do you give a newly loaded VFS? What if you have > > two loaded in different orders on different systems? > > > > The jab about string comparisons is just silly; bad programming is > > what's dangerous. The fact that people have been getting away with bad > > string handling for a while but aren't any more is no better or worse > > than people that used to get away with not range-checking values. > > 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? If the type numbers are static, you can't introduce a new VFS to a system without first rebuilding everything that uses the numbers. If the type numbers are dynamic, but still numbers, there's no way to know what they correspond to. Making them text strings means that you can add a new vfs and have a unique response from it that doesn't require a registry of number to name mappings. > 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. At the moment they don't even do that, they're indexes into a fixed array. > I > don't see why that has to be. If I bring in a KLD module named "nfs", I > fully expect it to do nfs filesystem stuff for me, whether or not I > loaded it first or second, I want it to do it based upon the name. Exactly, which is why you want it keyed by name, and not by offset in the VFS table like it is now. > Is > making it depend on an initially assigned number somehow evil? Yes; you have to administer the numbers. Look how much of a mess the major number assignment process creates. > Why > can't I just specify that some constant, oh, 69, means nfsv3? Might > well be that I misunderstand you, but it seems to go around your > example. The numeric "namespace" is too small, and the name doesn't mean anything useful. If the NFS VFS calls itself "nfs", then you can tell it's NFS. If you just loaded a VFS module and it says it's type #69, you're none the wiser unless you can go look the number up somewhere. > 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. You don't necessarily have a header file; the VFS may be a completely new animal. > 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). There's lots of agreement to work. There's just too much childish backstabbing and procrastinating over the implementation. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199810190240.TAA15643>