Subject: Re: 64 bit inode changes
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 08/16/2005 00:32:41
In article <20050815233221.GB1595@britannica.bec.de>,
Joerg Sonnenberger <email@example.com> 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 , 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.