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

[Poul-Henning Kamp]

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.