On Mon, Aug 15, 2005 at 10:53:37PM +0000, Christos Zoulas wrote:
> In article <20050815221426.GA1223@britannica.bec.de>,
> Joerg Sonnenberger  <joerg@britannica.bec.de> wrote:
> >> 	- nfs
> >
> >This is similiar to UFS. The structure of the NFS code just makes it
> >harder to correctly fix.
> 
> Ok, I will look into that next then. I thought that since you could
> export other than UFS over NFS it would have worked properly.

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.

> 
> >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.

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 :-)

> 
> >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.
_DIRENT_NEXT works just like your DIRENT_ADVANCE.

Joerg