Why is libc.so.1 mounted on Solaris 10?
ChrisS
do for Solaris 10 x86?
On Sparc it may be mounted as /platform/sun4u-us3/lib/sparcv9/
libc_psr.so.1 (libc_psr_hwcap1.so.1)
Casper H.S. Dik
>What does the /lib/libc.so.1 mounted to /usr/lib/libc/libc_hwcap2.so.1
>do for Solaris 10 x86?
It gives you a C library fine tuned for your specific hardware.
>On Sparc it may be mounted as /platform/sun4u-us3/lib/sparcv9/
>libc_psr.so.1 (libc_psr_hwcap1.so.1)
Same.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
ChrisS
Thanks Casper! Is there a document somewhere on that? I've had
difficulty finding a good blog or reference on this since Google shows
that file on anyone who's posted a mount of df output.
Why does it appear as a mounted file system? Someone asked me and I
had no idea.
Thanks again!
Chris
Alan Coopersmith
|On Jan 23, 3:48 pm, Casper H.S. Dik <Casper....@Sun.COM> wrote:
|> ChrisS <chris.sca...@gmail.com> writes:
|> >What does the /lib/libc.so.1 mounted to /usr/lib/libc/libc_hwcap2.so.1
|> >do for Solaris 10 x86?
|>
|> It gives you a C library fine tuned for your specific hardware.
|
|difficulty finding a good blog or reference on this since Google shows
|that file on anyone who's posted a mount of df output.
http://blogs.sun.com/darren/entry/whats_this_lofs_mount_onto
--
Alan Coopersmith * al...@alum.calberkeley.org * Alan.Coo...@Sun.COM
http://blogs.sun.com/alanc/ * http://people.freedesktop.org/~alanc/
http://del.icio.us/alanc/ * http://www.csua.berkeley.edu/~alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
Wayne
> ChrisS <chris....@gmail.com> writes in comp.unix.solaris:
> |On Jan 23, 3:48 pm, Casper H.S. Dik <Casper....@Sun.COM> wrote:
> |> ChrisS <chris.sca...@gmail.com> writes:
> |> >What does the /lib/libc.so.1 mounted to /usr/lib/libc/libc_hwcap2.so.1
> |> >do for Solaris 10 x86?
> |>
> |> It gives you a C library fine tuned for your specific hardware.
> |
> |Thanks Casper! Is there a document somewhere on that? I've had
> |difficulty finding a good blog or reference on this since Google shows
> |that file on anyone who's posted a mount of df output.
>
> http://blogs.sun.com/darren/entry/whats_this_lofs_mount_onto
>
That was a good post. But I still have to wonder why mount?
At first I thought this is the sort of optimization that should
be done at system install time. Then I thought about live CDs
and virtualization and realized an app or OS instance might
migrate from one host to another. Is that right? If so,
what happens when a running process "migrates" to another
host? Does a re-link occur to use a better suited library,
or do the app just use the library it was linked to when
it started, even after a migration? If it were me I would
just have the old process stopped on host-A and started
afresh on host-B.
But still I have to wonder why the boot time optimization of
libc.so is done with a mount, rather than just updating a
symlink or setting an ARCH environment variable used in
pathnames to libraries? Mounting seems an odd choice,
a hack really, for a boot-time selection of libc.so.
Would someone explain why this mechanism is used for this?
Thanks!
-Wayne
Casper H.S. Dik
>Thanks Casper! Is there a document somewhere on that? I've had
>difficulty finding a good blog or reference on this since Google shows
>that file on anyone who's posted a mount of df output.
>Why does it appear as a mounted file system? Someone asked me and I
>had no idea.
Because it's a mounted 'filesystem' (you can loopback mount files
ontop of other files)
Casper H.S. Dik
>At first I thought this is the sort of optimization that should
>be done at system install time. Then I thought about live CDs
>and virtualization and realized an app or OS instance might
>migrate from one host to another. Is that right? If so,
>what happens when a running process "migrates" to another
>host? Does a re-link occur to use a better suited library,
>or do the app just use the library it was linked to when
>it started, even after a migration? If it were me I would
>just have the old process stopped on host-A and started
>afresh on host-B.
You can't migrate a running application from one system to
another using Solaris.
>But still I have to wonder why the boot time optimization of
>libc.so is done with a mount, rather than just updating a
>symlink or setting an ARCH environment variable used in
>pathnames to libraries? Mounting seems an odd choice,
>a hack really, for a boot-time selection of libc.so.
>Would someone explain why this mechanism is used for this?
One reason might be that we still support a shared /usr for
diskless clients and that modifying /usr is seen as bad.
Also, when using a symlink and chaning it at boot, a migration
of the data to a different system might cause it to fail
to reboot: the system needs to boot with the least common'
denominator.
Not that I'm a great fan of the current solution; I think
I would have preferred it to be done though some linker magic.
Tim Bradshaw
>
> But still I have to wonder why the boot time optimization of
> libc.so is done with a mount, rather than just updating a
> symlink or setting an ARCH environment variable used in
> pathnames to libraries? Mounting seems an odd choice,
> a hack really, for a boot-time selection of libc.so.
> Would someone explain why this mechanism is used for this?
> Thanks!
I think mounting has a lot of good properties. Consider what would
happen with some kind of link-diddling thing if the machine fell over
while the link was being put in place, or if the target of the link
went away: you could end up in a situation where the link pointed
nowhere. That would be fairly bad (boot from media bad).
Making persistent changes to filesystems when you don't need to is not
really a great idea either - suddenly the mtime on /lib is the last
boot time of the machine. Mounting has the really good property that
it is *not* persistent.
Making *any* change to /usr will not work at all for non-whole-root
zones (or diskless clients).
Mounting also has the nice property that the underlying file is still
available to anything that has it open (this can be achieved in other
ways too), such as the program that performs the mount.
Setting an environment variable would require that it be set in the
parent of all processes on the machine, which means init would have to
do it.
I suspect traversing mounts is very quick, compared to the symlink
thing (look up pathname, read file, oh it's a link, start again),
though this may not count for much any more since things are now
quicker anyway and there is more and smarter caching. This used to
matter a fair bit with NFS a long time ago.
Emerson Seiti Takahashi
http://sunsolve.sun.com/search/document.do?assetkey=1-9-85550
Excerpt:
Why is this?
The mount points detailed have been created intentionally by
engineering. In basic terms, they are a platform specific enhancement
to ensure full application performance is achieved. This is done by
changing the way the Operating System fully utilizes the potential of
the CPU for the platform.
ChrisS
That document you references is for SPECTRUM accounts. Don't know
why it would be protected.
Anyways, this was apparently a good question and received good
feedback. All my questions were answered.
Thanks to all... GREAT feedback.
Chris