lkml.org 
[lkml]   [2000]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Return file types from readdir()
Albert D. Cahalan wrote:
> > A new syscall would be tidy, preferably one returning the binary layout
> > that Glibc returns to apps. Perhaps it should take an extra argument
> > like BSD's __readdirx for future whiteout/unionfs support.
> >
> > (readdir64 would not be implemented as a syscall -- you don't need 64
> > bit dir offsets).
>
> We should have 64 bits here. Directory offsets need not be actual
> offsets into a linear directory file. The extra bits will be useful for
> filesystems with complex directories. Consider what the offset means
> for a B-tree directory or worse.

Ok, but bear in mind that on 32 bit architectures, the 32 bit offset
will be used unless you specifically request large file support. To
take advantage of the extra bits, you have to be willing to refuse to
read a directory that needs those bits, in much the same way that we
refuse to open large files when O_LARGEFILE is not set.

> BTW, if you were to add a new system call, do it right. Doing the
> job right means using a very general interface that has low kernel
> overhead. Glibc is not supposed to dictate kernel interfaces.

Of course I'd be sure to consult you in that case :-)

The Glibc thing, not counting large-file support, is not a big deal.

The only Glibc issue at the moment is that Glibc calls the kernel's
getdents, and then copies the result while changing the format. It's a
minor inefficiency (and it has a couple of bugs (makes note)).

It would be no big deal to simply return the right format, if a new
system call is implemented.

In that case it would be generous to permit a file pointer in/out
argument, so that Glibc's __getdirentries function can be implemented
more or less directly. Currently it needs an extra lseek for each call.
(Actually that's omitted in current Glibc versions, but the recovery
code for an error case erroneously assumes lseek(SEEK_CUR,
-getdents_retval) seeks back to the original position, so the extra
lseek prior to getdents will have to be put back).

But as we've noted, no syscall is needed for d_type. Now, if only Linus
would respond -- I've offered this patch a few times over 3 months
without a response...

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.047 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site