cvs commit: src/sys/kern vfs_subr.c src/sys/fs/devfs devfs_vnops.c

[Scott Long]

Poul-Henning Kamp wrote:
> In message <43735F4C.7070307 at samsco.org>, Scott Long writes:
> 
>>Poul-Henning Kamp wrote:
>>
>>>In message <437351BB.6000103 at samsco.org>, Scott Long writes:
>>>
>>>
>>>
>>>>Putting the cookie into the dirent means either changing the size of the
>>>>dirent struct and breaking the userland ABI (almost as bad as changing
>>>>the size of stat, but not quite), or making a 'kdirent' struct and then
>>>>manually shifting and copying it to a dirent struct.
>>>
>>>
>>>Not really that bad.
>>>
>>>My idea was to make a 
>>>	struct kdirent {
>>>		struct dirent	foo;
>>>		cookie stuff	bar;
>>>	}
>>>
>>>Filesystems would call vfs_read_dirent() with a struct kdirent and
>>>depending on the userland/kernel flag in the uio vfs_read_dirent()
>>>would copy either the entire kdirent or only the userspace dirent.
>>>
>>>
>>>>What I really think this is is a ploy by PHK to get someone motivated to
>>>>fix it for him ;-)
>>>
>>>I'm generally in favour of people doing work so I don't have to but
>>>in this particular case that was not the motivation :-)
>>>
>>>(At least you can't prove anything!)
>>>
>>>Poul-Henning
>>>
>>
>>I still don't see how this is supposed to work.  VOP_READDIR() doesn't
>>return the dirent array to the caller, it's directly copied to the user
>>buffer.
> 
> 
> vfs_read_dirent() is called from the filesystem, and determines
> what to copy where.
> 
> If the copy is to kernel space, the kdirent will be used and NFS
> gets its cookies.
> 
> If the copy is to user space, the dirent will be used and the
> ABI and API is unchanged.
> 

Ok, so now you need to teach the consumers like NFS to de-interleave the
cookies from the dirents, which isn't all that straight forward because
the dirents are all various sizes.  Not a hard problem to solve, but I
don't see what the net gain is here.

Scott