In article <20050815233221.GB1595@britannica.bec.de>,
Joerg Sonnenberger  <joerg@britannica.bec.de> wrote:
>
>The problem with NFS is that it reuses the transfer buffer and alters
>the dirent inplace. nfs_readdir -> nfs_bioread -> nfs_readdirrpc is the
>chain. I'm still thinking about how to best solve this. So far, I've
>been thinking about just follow the UFS example and allocate a transfer
>buffer, drop the direct entries there (since that's what NFS is actually
>using too) and convert it afterwards.

Yes that would be the simplest.

>> >It might also be a good point to remove the hard-wired d_name length in
>> >dirent. The constant for its length should at the very least be NAME_MAX
>> >and not MAXNAMLEN.
>> 
>> I have not changed NAME_MAX [256], but I have used 512 as MAXNAMLEN now.
>> I think I will leave NAME_MAX to 256 for now.
>
>One reason why I didn't change MAXNAMLEN is because it is used by UFS
>for the layout of struct direct. The headers already play dirty games
>with undefining it, so that can lead to strange results.

Yes, but I did not want to break programs that use MAXNAMLEN. Anyway
my change seems to work now.

>What I meant was to declare d_name either as incompletely array or
>one length array, like e.g. Solaris does. Programs would have to explicitly
>allocate space for the name, but it also means that they work
>independent of later changes. In DragonFly, I'm working on completely
>eliminating d_reclen, but that really is a lot of work :-)

Yes that would be nice. I will leave ours for now to have a full array
definition, so that userland programs don't need to change.
 
>> >I've choosen _DIRENT_ALLOC and _DIRENT_NEXT for the
>> >macros to determine the filesystem dependent struct dirent size and
>> >compute the address of the next dirent. I think it would be helpful if
>> >we can agree on one convention :-) The underscore was choosen because
>> >this macros are not part of SUS.
>> 
>> Sounds like fine names to me. I will change mine. Does your ALLOC take
>> one or two arguments? What about NEXT?
>
>_DIRENT_ALLOC takes one argument, the length of the filename.

And returns a size, right? Then a better name would be _DIRENT_RECLEN(). I
am passing the struct too, for symmetry with DIRENT_ADVANCE.

>_DIRENT_NEXT works just like your DIRENT_ADVANCE.

I pass the struct here, so that I can re-use the macro for struct direct
and struct dirent12 (our compat code). If we don't have the same arguments,
then it is not worth to call them the same name.

christos