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:3.960 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site