Date: Wed, 13 Dec 1995 18:37:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: current@freebsd.org Subject: VOP_READIR revisited Message-ID: <199512140137.SAA00700@phaeton.artisoft.com>
next in thread | raw e-mail | index | archive | help
This message is a revisit of the VOP_READDIR issues with cookies, NFS, and user space exporting. Background: The VOP_READDIR call implements the getdirentries (getdents if you are a POSIX compliant OS) system call. It returns the entries in a file system independent structure, and uses a "cookie" mechanism to allow the search to restart on non-directory block entry boundries... this is typically used for NFS single entry and repositioning operations. The ufs_readdir version of VOP_READDIR for UFS derived file systems MALLOC's cookie buffers, and in general wreaks havoc. Proposal: After much consideration, it seems that the soloution would be to have the VOP_READIR return the directory block in the file system native format. This means that there would need to be an additional per-FS type VOP_EXPORTDIR or VOP_DIRCVT or whatever that did the actual copy to the user buffer before exporting it. This would save the cookie complication and the local allocations in the endian dependent cases, as well as simplifying support to not need two copies when the directory entries weren't in the exported format on the media they were being read from (ISO, DOS, NFS client). This would also eliminate the need for specific knowledge of the buffer size on the way down. If an FS, like the union FS, needed to interpret the directory names locally, then it would be possible for it to call the VOP_DIRCVT with a UIO_SYSSPACE argument for a local buffer. But this buffer requirement would be limited to the file system with this requirement, a small fraction of the FS's currently supported. Additionally, the VOP_DIRCVT could be given an export count so as to avoid overrunning the target buffer. Conclusion: Besides allowing the conversion to/form a Unicode name space (for instance, an NTFS or Win95FS with long name support) at the caller layer rather than enforcing the restriction below the VFS layer, it would allow export of multiple name spaces (for instance, DOS, Mac, and UNIX on a NetWare FS for a local volume or for a NetWare client FS). It would also allow export of multiple names for, for instance, an SMB server in the kernel that services both Win95 and WFWG systems. I believe that it also resolves all the outstanding "cookie" issues cleanly, without unduly complicating the interfaces (in fact, UFS complication is decreased slightly and VOP_READDIR in msdosfs, cd9660fs, hpfs, ntfs, etc. becomes vastly *less* complicated for NFS exportable versions of the file systems). Supercedes: This propoposal replaces my previous proposol of a null FS export layer that would have to be stacked on a fer FS basis and was "client specific" in implementation (ie: one for NFS as a VFS client, one for the system calls as a VFS client, etc.). 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?199512140137.SAA00700>