On Mon, May 09, 2005 at 02:33:32PM -0700, Thomas Bushnell BSG wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: > >> Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > >> > >> > The number of directory entries in /usr/lib should not make any > >> > difference to a modern GNU linker on a modern filesystem, unless > >> > you have thousands or millions of them. > >> > >> Why? Is there magic now? > > > > What magic do you need? Most filesystems can open a file without > > doing an O(n) lookup, especially from the dentry cache. > > Huh? The dentry cache turns ls into O(n) instead of O(n^2), but that > doesn't mean that searching every item in the directory isn't still > necessary, unless the directory is hashed or stored in as a tree.
You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. > Surely the reason who have these different directories is to make > logical distinctions, keeping different kinds of things in different > directories. If the argument for combining libexec and lib is that > "it does no harm", then I see why we should not put *everything* into > lib. It would make it simpler. > > So the question is: why is it useful to make some distinctions > (including non-sensical ones like /usr vs. /) but not this one? That's a completely different question... which I don't think I need to answer. I was responding to your invalid criticism of the linker. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
