This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Jakub Jelinek <jakub@redhat.com> writes:
> On Tue, Jul 03, 2007 at 01:45:13PM -0700, Ulrich Drepper wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Andreas Jaeger wrote:
>> > What do you think now?
>>
>> Lot's of formatting and little style/semantic problems all over the place.
>
> ...
>
> I haven't seen any progress with this, so in order to speed up the process
> I tried to address all issues Uli and Jim raised plus several minor or
> less minor things.
>
> Attached is a new patch, plus interdiff from the last patch Andreas posted.
> I have briefly tested it, but nothing extensive.
Thanks a lot Jakub - I just did not had time so far but wanted to follow
up!
> The remaining issues I'd like to discuss before changing them are:
If everybody is fine with your version, I suggest that it goes into cvs
- and the next steps are done on top of it.
> 1) ldconfig uses the /var/cache/ldconfig/aux-cache cache only to speed up
> mapping of the cache_entry_id -> { flags, osversion, soname }
> so what's the point of aux_cache_file_entry containing value (aka path)
> or hwcap?
I don't see a need for them either anymore.
> 2) the aux_entries linked list will usually contain roughly 2000+ entries,
Mine has 2053 - so I agree ;-)
> isn't that above the count where using a simple hash table or rb tree
> (hsearch_r is probably a bad idea, as it needs strings as keys,
> but we could either implement our own trivial hash table
> (say hashing with nextprime (aux_cache->nlibs) hash table
> entries with chains), or could grab from libiberty Vlad's hashtab.c
> (that's probably overkill, we know how many entries we have, no need
> to ever resize it), or use tsearch).
Yes, some other data structure might be better.
> 3) couldn't the aux-cache entries also contain negative lookups?
> E.g. we have *.so linker scripts in the directories, that can be
> cached as cache_entry_id -> { -1, -1, 0 } or something similar
> to denote non-DSO.
We have so few linker scripts that I doubt this optimization is worth
it. Otherwise: Yes, it could be done.
Andreas
--
Andreas Jaeger, Director Platform/openSUSE, aj@suse.de
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Attachment:
pgp00000.pgp
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |