Date: Sun, 18 Oct 1998 20:32:15 -0400 (EDT) From: Chuck Robey <chuckr@mat.net> To: Mike Smith <mike@smith.net.au> Cc: Terry Lambert <tlambert@primenet.com>, Andy Farkas <andyf@speednet.com.au>, freebsd-chat@FreeBSD.ORG Subject: Re: mount flags Message-ID: <Pine.BSF.4.05.9810182016460.348-100000@picnic.mat.net> In-Reply-To: <199810190009.RAA14961@dingo.cdrom.com>
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? 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. 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. Is making it depend on an initially assigned number somehow evil? 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. 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). 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. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- 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?Pine.BSF.4.05.9810182016460.348-100000>