lkml.org 
[lkml]   [2001]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Trond Myklebust wrote:
> >>>>> " " == H J Lu <hjl@valinux.com> writes:
>
> > I much prefer to have a new getdents system call which will
> > also return d_type so that the 32 bit function in glibc can use
> > this new getdents instead of getdents64.
>
> That could also be done, however it seems odd to be adding a new
> 32-bit interface after the point when we're supposed to all have moved
> to 64 bits.

Indeed, getdents64 -> 32 conversion is hardly performance critical
anyway.

> BTW: does anybody anywhere actually use d_type? Certainly the standard
> utilities such as 'find' or 'ls' don't seem to have been adapted
> yet: I hacked up a version of NFSv3 that actually filled d_type
> (by using readdirplus rather than readdir) but I've yet to find
> any 'off the shelf' software, that uses the extra information.

Look for `treescan' via Google. It uses a number of heuristics to
optimise a recursive directory search, and one of those is d_type if
available. Though it dates back to a time before getdents64 (I hacked
getdents to return d_type).

d_type is quite effective for `find' type scans. I really ought to
release an updated treescan -- the intent was always to replace the
backend of `find' but I got caught up trying to optimise the order of
open/readdir/close sequences and then on to other things.

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

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