Darren J Moffat wrote:
> Bart Smaalders wrote:
>
>> So what would you do, given that we had to change out big
>> chunks of libc and not just mem* routines ala sparc?
>
> As I've mentioned in the past when this was brought up. I would like to
> see the information from moe(1) stored in the /var/ld/ld.config file to
> store the information about which $PLATFORM/$HWCAP library is most
> appropriate for this system. ld.so.1 already looks for that ld.config
> file on every use anyway. I think there is almost enough stuff in
> ld.config already to support this.
>
That would work, except that:
1) Anyone defining their own ld.config files would lose the
hardware customization.
2) References to /usr/lib/libc.so.1 would always yield the slow
library.
3) The use of a custom libc in an unusual location would be
visible to users via pldd, pmap, dbx, mdb, etc.
While the solution we chose did introduce some bugs, it also avoided
others and is actually reasonably high performance.
>> I know of the flash problem.... what was gnome's problem?
>
> The file selection dialog was showing the libc lofs mounts as "top
> level" mounts in the GUI. The problem was fixed several builds ago, I
> think the fix was to have the GNOME code ignore lofs mounts.
>
This of course was a bug in Gnome :-). Seriously, I see lofs mounts
becoming more popular for other reasons; deciding what to expose to
users is a reasonably complex UI decision.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
