Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Scott Long writes:
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, 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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
