Date: Fri, 25 Aug 95 17:20:04 MDT From: terry@cs.weber.edu (Terry Lambert) To: current@freebsd.org, hackers@freebsd.org Subject: UNIFIED FILE SYSTEM PATCHES, PLEASE APPLY Message-ID: <9508252320.AA13133@cs.weber.edu>
next in thread | raw e-mail | index | archive | help
I have just uploaded a set of patches that are general cleanup patches for file system related code, with special emphasis on cleanup of the use of the namei() interface. freefall.cdrom.com:~terry/UNI.diff.gz There is no README for this patch set. Mostly, these patches deal with using NDINIT() rather than manually initializing the equivalent pieves of the nameidata structure before passing the data to namei(). The biggest offenders in this area are the binary compatability modules. There are several places where the credentials were initialized from the proc being passed before namei was called. This is broken, since the first thing namei does is set the credentials from the process passed in anyway. These patches also prereserve two manifest constants for use in multibyte aware/capable file systems. This reservation has no effect on the operation of the code, though it does cause some integer bit values to be recoded as hexadecimal values. This is, in general, a good thing in any case. I've also patched flags checking of the mnt_maxsymlinklen field to use the macro for format detection, and renames the FSFMT to OFSFMT (apropriate, considering it returns "true" when the file system format is old and "false" when it is new). Finally, there are patches to dir.h to make the DIRSIZ macro independent of compiler structure alignment, internal changes to the dirent/direct structures, and support for sizing of non-struct direct objects. This last resolves a subtle bug in ufs_lookup.c regarding a possible 4 byte discrepancy in directory entries during compaction on mounts of pre-4.4 (FreeBSD 1.x) file systems. I went looking for it when my NetBSD 0.8 -> FreeBSD 2.x upgraded system started showing occasional directory corruption for files renamed from some name to some other name where newnamelen % 4 == 3. The change in the DIRSIZ macro results in *exactly the same assembly code* as the previous macro definition for an unmodified struct direct. THIS IS NOT ADDITIONAL OVERHEAD, EVEN THOUGH IT LOOKS LIKE IT IS -- THE COMPILER GENERATES THE SAME ASSEMBLY, SINCE A MULTIPLY BY A MANIFEST CONSTANT ONE IS ELIMINATED! Please commit these patches. Regards, Terry Lambert terry@cs.weber.edu --- 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?9508252320.AA13133>