It is currently Thu, 20 Jan 2022 05:02:50 GMT



 
Author Message
 relationship between /usr/bin/adb and /usr/bin/ps
hi all,

has anyone notice the relationship between this 2 files??

whenever u change the permission of either file, it also apply to the
other file as well.

for example

orginal - r-xr-xr-x root root /usr/bin/adb
          r-xr-xr-x root root /usr/bin/ps

#chmod 554 /usr/bin/adb

after -   r-xr-xr-- root root /usr/bin/adb
          r-xr-xr-- root root /usr/bin/ps

anyone has any idea on this.

Thanks



 Sat, 24 Mar 2007 21:59:41 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps
Those files and various others are hard links to the same file
which is a wrapper that eventually calls the right

/usr/bin/sparc<7|9>/<cmd>

depending on the current architecture.

--
Stephane



 Sat, 24 Mar 2007 22:13:48 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps
In article <e499b1b4.0410050559.7e0b4...@posting.google.com>,

% ls -li /usr/bin/adb /usr/bin/ps /usr/lib/isaexec
        77 -r-xr-xr-x  56 root     bin         9732 Sep 24 05:19
/usr/bin/adb
        77 -r-xr-xr-x  56 root     bin         9732 Sep 24 05:19
/usr/bin/ps
        77 -r-xr-xr-x  56 root     bin         9732 Sep 24 05:19
/usr/lib/isaexec

Note that all columns but the last are the same -- the first one
is the "inode" number, which uniquely identifies a file within a
particular mount-point.  The third column is the "link count", which
indicates how many directory entries name this file.

So /usr/bin/adb and /usr/bin/ps are hard-links (see ln(2)) to
/usr/lib/isaexec, which is a small wrapper around isaexec(3C).
The real binaries for adb and ps live in subdirectories of
/usr/bin:

% ls -l /usr/bin/*/adb /usr/bin/*/ps
-r-xr-xr-x   2 root     bin       511756 Sep 24 08:59
/usr/bin/sparcv7/adb*
-r-xr-xr-x   2 root     bin       602416 Sep 24 09:01
/usr/bin/sparcv9/adb*
-r-xr-xr-x   1 root     bin        38920 Sep 24 05:25
/usr/bin/sparcv9/ps*

(this is a Solaris 10 machine, which no longer supports 32-bit SPARC
kernels, so /usr/bin/sparcv7/ps is not useful.  In Solaris 9, it will
still exist)

Read isaexec(3C) for details on how it works.

Cheers,
- jonathan



 Sat, 24 Mar 2007 22:31:55 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps
On 2004-10-05 14:59:41 +0100, shiq...@email.com (shiquan) said:

They aren't two files, they're hardlinks to the same file.  Why?  Read on...

A blast from the past - as I said in May 2002 in Message-ID:
<3CF78C9C.D0E2F...@sun.com> (though extended somewhat):

In general, Solaris will run 32 bit commands on a 64 bit OS quite
happily. There are however exceptions. One exception is when a command
needs to understand internal kernel data structures. In such cases two
versions of the command need to be provided, one compiled for 32 bit and
one for 64 bit operation. If you look in /usr/bin/sparcv7 and
/usr/bin/sparcv9 you should see the same commands listed, however if you
use "file" you'll see that those in /usr/bin/sparcv7 are 32 bit and
those in /usr/bin/sparcv9 are 64 bit.

In order to select which version of the command is run, the system uses
"isaexec". This is effectively a wrapper which works out which OS
version is running then execs the appropriate command. You put 32 bit
commands in /usr/bin/sparcv7 and the 64 bit versions in /usr/bin/sparcv9
and have a copy of isaexec in /usr/lib/isaexec (In fact isaexec can live
anywhere as long as it's on the same filesystem as the commands to be
run). Then you make HARD links from /usr/lib/isaexec to
/usr/bin/whatever - you should see that each command in
/usr/bin/sparcv[79] is represented in /usr/bin as a command that's
really a hardlink to /usr/lib/isaexec

For example:

$ cd /usr/bin
$ ls -li ps
     66970 -r-xr-xr-x  42 root     bin        10024 May  1 07:36 ps

Note the "42" - there are 42 links to this file. Hardlinks have the same
inode number, so they'll all be inode 66970

$ find /usr -xdev -inum 66970
/usr/lib/isaexec
/usr/bin/newtask
/usr/bin/nohup
/usr/bin/prctl
/usr/bin/prstat
/usr/bin/ps
/usr/bin/savecore
/usr/bin/setuname
/usr/bin/uptime
/usr/bin/w
/usr/bin/pargs

(and so on - the rest snipped).

Don't expect to get exactly the same results on your machine BTW - I can
pretty much guarantee you won't be running the same release of Solaris
as me.

The idea is that you can distribute a binary optimised for (or even
dependent on) several architectures as a single package by putting the
differently-optimised versions in various subdirectories and letting
isaexec sort out which one will be run on a particular architecture.

You're not limited to /usr/bin/sparcv[79] in fact; isaexec will
(effectively) do an "isalist -v" and run things that are in the first
directory whose name matches (IYSWIM).On this machine isalist -v returns

sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld
sparcv7 sparc

If I run "/usr/bin/ps" (really /usr/lib/isaexec with an argv[0] of
"/usr/bin/ps") it'll try for /usr/bin/sparcv9+vis/ps (and not find it
on this box), then try /usr/bin/sparcv9/ps (which is there so it'll run
it).

On a different machine (rather larger than this one) isalist -v returns

sparcv9+vis2 sparcv9+vis sparcv9 sparcv8plus+vis2 sparcv8plus+vis
sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc

On that machine the first place isaexec looks is /usr/bin/sparcv9+vis2

So if I had two versions of a binary, one optimised for sparcv9+vis2
and one for  sparcv9+vis, I could have both installed on both machines
but ensure that only the appropriate one was run on the appropriate
machine.

You're not limited to /usr/bin either - isaexec takes the pathname of
the command and puts the "derived from isalist" bit in, so if your
command lives in /opt/mystuff/binaries you'd need
/opt/mystuff/binaries/sparcv9 and so on for the variously-optimised
versions. You'd also need a copy of isaexec somewhere on the same
filesystem as /opt/mystuff/binaries.

Then hardlink your command in /opt//mystuff/binaries to (for instance)
/opt/lib/isaexec and have your "real" commands in
/opt/mystuff/binaries/sparcv9 (and so on).

Here endeth the banging on at some length.



 Sat, 24 Mar 2007 23:05:16 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps

Just out of interest, why are nohup and setuname amongs them? I would
understand that everything dealing with /proc in some way has to be
bitness-aware, but why these two?

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!



 Sat, 24 Mar 2007 23:32:25 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps
On 2004-10-05 16:32:25 +0100, Dragan Cvetkovic <m...@privacy.net> said:

setuname is kernel-aware (unsurprisingly, since it makes changes to the
utsname structure in the kernel)

ldd /usr/bin/sparcv9/setuname
        libkvm.so.1 =>   /usr/lib/64/libkvm.so.1

so if you try to run a 32-bit setuname on a 64 bit kernel it breaks.

# isainfo -k
sparcv9
# /usr/bin//sparcv7/setuname -n foo
Internal error: 14
#

As for nohup I haven't the faintest idea - might there be problems with
a 32-bit nohup attempting to execute a 64-bit binary (or vice versa)?
Casper? Thomas? Anybody?

--
Tony



 Sat, 24 Mar 2007 23:49:55 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps
In article <lm4ql9faeu....@privacy.net>,
 Dragan Cvetkovic <m...@privacy.net> wrote:

See the (new in S9) "-p" and "-g" options to nohup(1) -- they have to
attach to the process using /proc.

setuname(1M), on the other hand, appears to *write* the new values
directly into /dev/kmem, which seems quite mad.

- jonathan



 Sun, 25 Mar 2007 00:02:05 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps

I see. Thanks. Haven't used nohup for a while (actually, I don't remember
using nohup ever).

Ouch. Good design showing, eh? :-)

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!



 Sun, 25 Mar 2007 00:18:24 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps
In article <lmvfdpdtpr....@privacy.net>,
 Dragan Cvetkovic <m...@privacy.net> wrote:

Well, it came from SVr4.0.  Why anyone would *want* to change 'uname -s'
from "SunOS" to something else is beyond me.

Cheers,
- jonathan



 Sun, 25 Mar 2007 00:25:52 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps

$ ls -i /usr/bin/adb
      1416 /usr/bin/adb
$ ls -i /usr/bin/ps
      1416 /usr/bin/ps
$

As you can see, they have the same i-node number.  On your
system, the number will be different, but adb and ps will
still have the same one.  They are actually two different
pathnames for the *same file*.  Any change you make via
one pathname will show up in the other.
--
             Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"



 Sun, 25 Mar 2007 00:38:56 GMT   
 relationship between /usr/bin/adb and /usr/bin/ps

Depends when the Sun Marketing Department justify the case for doing so.
The ability to change `uname -s` is forward planning ;-)



 Sun, 25 Mar 2007 03:58:55 GMT   
 
   [ 11 post ] 

Similar Threads

1. /bin /usr/bin /usr/local/bin etc

2. /usr/bin/ls /usr/ucb/ls /usr/local/bin/ls

3. /usr/local/bin/perl ->/usr/bin/perl

4. /usr/xpg4/bin/tr bug (or don't use /usr/xpg4/bin)

5. /usr/dt/bin/dtksh and /usr/bin/ksh

6. why /usr/bin/mailx /usr/bin/mail set the group to be that of the sender

7. /usr/local/bin vs. /usr/bin

8. #!/usr/local/bin/perl -w || /usr/bin/perl -w

9. #!/usr/bin/perl or #!usr/bin/perl


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software