Ragnar Kj=C3=B8rstad wrote:
quoted text
> I think Andreas already wrote that "ls --color" is the default in mos=
t
quoted text
> distributions and needs to stat every file.

Remove the :ex entry from LS_COLORS and try again.


quoted text
> "find" is already smart enough to not call stat when it's not needed,
> and make use of d_type when it's available. But in many cases stat is
> still needed (such as with -user)
>=20
> find kernel_old -not -user 1002:
> 83.63% 173.11s  0.319ms  543338 lstat
> 16.31%  33.77s  5.242ms    6442 getdents64
>  0.03%   0.06s 62.882ms       1 execve
>  0.01%   0.03s  6.904ms       4 poll
>  0.01%   0.02s  8.383ms       2 connect

And how often do the scripts which are in everyday use require such a=20
command?  And the same for the other programs.

I do not doubt that such a new syscall can potentially be useful.  The=20
question is whether it is worth it given _real_ situations on today's=20
systems.  And more so: on systems where combining the operations really=
=20
makes a difference.

Exposing new data structures is no small feat.  It's always risky since=
=20
something might require a change and then backward compatibility is an=20
issue.

Introducing new syscalls just because a combination of two existing one=
s=20
happens to be used in some programs is not scalable and not the=20
Unix-way.  Small building blocks.  Otherwise I'd have more proposals=20
which can be much more widely usable (e.g., syscall to read a file into=
=20
a freshly mmaped area).  Nobody wants to go that route since it would=20
lead to creeping featurism.  So it is up to the proponents of=20
readdirplus to show this is not such a situation.

--=20
=E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro S=
t =E2=9E=A7 Mountain View, CA =E2=9D=96
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html