Date: Tue, 24 Sep 1996 01:56:37 +1000 From: Bruce Evans <bde@zeta.org.au> To: fs@FreeBSD.org Subject: untangling dirent macros Message-ID: <199609231556.BAA24393@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
I found that cd96660_vnops.c and devfs_vnops.c use the deprecated compatibility header <sys/dir.h>. Several other places include it but don't actually use it. <sys/dir.h> attempts to include the application header <dirent.h>, but because of the bogus -I$S/sys in the kernel Makefile, it actually includes <sys/dirent.h>. This works because kernel sources really want <sys/dirent.h> anyway. When I removed -I$S/sys, <sys/dir.h> started including the application header. This worked too. cd96660_vnops.c and devfs_vnops.c only need the DIRSIZ() macro from <sys/dir.h>. ufs avoids <sys/dir.h> by having its own copy of the macro in <ufs/ufs/dir.h>, where the macro describes the on-disk layout. The on-disk layout happens to be suitable for returning almost directly in ufs_readdir(), at least on 32-bit machines (I think there might be alignment problems for future(?) 64-bit machines). I think a version of the macro that gives minimal padding of the name for readdir() should be defined in <sys/dirent.h> and all the names should be unique. Maybe rename the ufs version UFS_DIRSIZ(). Maybe <machine/dirent.h> is required to sometimes specify 64-bit alignment. There is a similar problem with DIRBLKSIZE. It is defined as 1024 in <dirent.h>, but the kernel normally never sees or uses that. ufs uses DEV_BSIZE=512. nfs_serv.c and nfs_vnops.c include <ufs/ufs/dir.h> so that they can misuse the ufs value. ext2fs_lookup.c includes <ufs/ufs/dir.c> so that it can misuse the ufs value and lots more ufs stuff. I think a generic value for this should be defined in <sys/dirent.h>. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609231556.BAA24393>