Date: Tue, 22 Jul 1997 13:08:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@nlsystems.com (Doug Rabson) Cc: bde@zeta.org.au, current@FreeBSD.ORG, dfr@FreeBSD.ORG Subject: Re: more WebNFS merge bugs, one serious Message-ID: <199707222008.NAA13956@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95q.970722163853.341A-100000@herring.nlsystems.com> from "Doug Rabson" at Jul 22, 97 04:44:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The WebNFS merge broke binary compatiblity of mount_msdos for the same > > reason that it broke binary compatiblity of mount_cd9660. The usual > > symptom is bizarre modes for all files under the mount point. This is > > because for old mount binaries, the extra field in export_args is taken > > from the uid arg, the uid arg is taken from the gid arg, the mode arg > > is taken from stack garbage, and the corrupted args affect everything > > under the mount point. > > Sigh. How do you think I should fix this? It would be hard to cope with > the old structure since the args are different for each mount. I think this should be delt with by passing mount options as environment which is accessed from the kernel. This provides a nice clean API for stuffing arbitrary data to the kernel, albiet without namespace overloading (which is a good thing, IMO). I'd like to see options get set in the environment, and then the environment passed down to the system call. Ideally, the kernel would access the process environment to do the deed; there are some stupid issues of envp in the ANSI and POSIX standards which dictate implementation, in this regard, however. Alternately, you could pass an envp down representing command line options. This would beat the hell out of the "sorta-canonical-but-not" method of mount call argument parsing. I believe the NFS export stuff needs to move out of the per FS mount code in any case. I'm not to worried about backward compatability, since very few programs that aren't part of the standard set of BSD programs (and therefore under BSD control) ever call the mount(2) system call, etc.. > Thanks for the fixes. Is the hash stuff still used by the name cache? I > can't remember exactly what Poul did to it when he was changing the cache. Some of the has precalculation is done to ensure that the speed of the operation is better (on a per component basis, that is). This is actually broken, since lookup is permitted to eat multiple components on a per FS basis. I think that there needs to be a flag to determine on a per FS instance basis whether or not directory name entry caching occurs. I'd like to see the cache hit occur *without* a call to VOP_LOOKUP, eventually. This would also get rid of most of the remaining SAVENAME flag bogosities from delete vs. rename. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707222008.NAA13956>