Dxreaddir (1/2)

[Julian Reschke <reschke@GOEDEL.UNI-MUENSTER.DE>]

New systemcall Dxreaddir (?)(!)
-------------------------------

We already discussed that, with no result. Problem: the current model of 
the directory operations requires that you make two calls (Dreaddir + 
Fxattr) for every file in a directory. Let's recall the arguments:

`The current API reflects what POSIX documents and what is needed for a 
straighforward implemention of opendir/readdir/closedir.'

This is right, but POSIX 1003.1 is the documentation of the C bindings, 
not necessarily an OS interface. There's no reason why an operating system 
shouldn't provide more efficient services which could then be used by the 
C library to implement opendir/readdir/closedir/stat.

`The path lookup in the subsequent Fxattr call could be sped up by caching 
file cookies.'

Very well. Obviously it's not that easy, otherwise somebody would have 
done it already. And, even if Fxattr would be made faster, it will *still* 
be faster just to make one call instead of two.


This is why I've added the new system call:

Dxreaddir (short lngth, long dirh, char *buf, XATTR *xap, long *xr);

It works just like calls to Dreaddir and Fxattr. In my test application 
(find), the time to walk through my C partition dropped from 17 seconds to 
7 seconds. Not bad for ~20 new lines in the kernel... (with most of them 
comments and declarations).

Some more thoughts:

- Dxreaddir doesn't change the FS interface.

- Dxreaddir still allows to separately detect failures to read the
  directory entry (Dreaddir) from failures to read the 'inode' (Fxattr), 
  because the return value of the second operation is stored in a separate 
  return code.

- Dxreaddir doesn't follow symbolic links. Reasons for that (besides 'keep 
  it simple'): following the link requires new lookups. If the caller 
  needs the 'stat' type information *and* the file was a symbolic link, he 
  can still call Fxattr to get what he needs.

- Even if this shouldn't be implemented in MiNT (WHY not?), it would still 
  be good to *define* such an OS call. Other operating system writers 
  might want to support it :-)

- The FAT file system is not the only FS that stores the file attributes 
  along with the names (and in this case, Dxreaddir will have the largest 
  gains). Just take a look at a CD ROM. And with the Chicago FS -- that's 
  what people will want to have on removable media for data transfers with 
  the DOS world -- we'll still have no inodes and links, but long names.



-- 
---------------------------------------------------
Julian F. Reschke, Hensenstr. 142, D-48161 Muenster
 eMail: reschke@math.uni-muenster.de jr@ms.maus.de
___________________________________________________