home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sun / admin / 9526 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  1.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!sdd.hp.com!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: libc.so.* and libc.sa.*: kernel arch dependent?
  5. Date: 17 Dec 1992 03:59:31 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 24
  8. Message-ID: <1gotv3INNeqr@early-bird.think.com>
  9. References: <1992Dec16.224530.21853@rigel.econ.uga.edu>
  10. NNTP-Posting-Host: gandalf.think.com
  11.  
  12. In article <1992Dec16.224530.21853@rigel.econ.uga.edu> glenn@rigel.econ.uga.edu (Glenn F. Leavell) writes:
  13. >While rebuilding /usr/lib/libc.so.* and /usr/lib/libc.sa.*, an interesting
  14. >question has come up.  These libraries are, of course, application architecture
  15. >dependent, but are they kernel architecture dependent?
  16.  
  17. No.  If they were, they'd be in /usr/kvm rather than /usr/lib (there would
  18. be links in /usr/lib, of course).
  19.  
  20. Consider: the shared libraries are compiled from the same sources and
  21. headers as the static libraries, and programs linked statically with the
  22. latter are portable between different kernel architectures.
  23.  
  24. In general, programs are only kernel-dependent if they access /dev/mem or
  25. /dev/kmem, and such programs have to be setuid.  Since libraries can't be
  26. setuid, they shouldn't try to access them.  (Strictly speaking, this rule
  27. could be violated for those system functions that are documented as being
  28. restricted to the superuser, since a user-mode implementation might work by
  29. accessing /dev/mem -- however, this isn't how any Unix system calls are
  30. implemented.)
  31. -- 
  32. Barry Margolin
  33. System Manager, Thinking Machines Corp.
  34.  
  35. barmar@think.com          {uunet,harvard}!think!barmar
  36.