home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / solaris / 296 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  1.9 KB
  1. Xref: sparky comp.unix.solaris:296 comp.unix.bsd:8797
  2. Path: sparky!uunet!auspex-gw!guy
  3. From: guy@Auspex.COM (Guy Harris)
  4. Newsgroups: comp.unix.solaris,comp.unix.bsd
  5. Subject: Re: Solaris 1.1 vs. Solaris 2.0 (BSD vs AT&T)
  6. Message-ID: <15468@auspex-gw.auspex.com>
  7. Date: 12 Nov 92 22:30:59 GMT
  8. References: <kzin.721442926@cc.gatech.edu> <BxLz6x.EL7@cs.uiuc.edu>
  9. Sender: news@auspex-gw.auspex.com
  10. Followup-To: comp.unix.solaris
  11. Organization: Auspex Systems, Santa Clara
  12. Lines: 33
  13. Nntp-Posting-Host: auspex.auspex.com
  14.  
  15. >If the program accesses the kernel (not just by system calls)
  16.  
  17. I presume by "access the kernel" you mean things such as opening
  18. "/dev/kmem" and looking at kernel data structures (or using the "kvm"
  19. library).
  20.  
  21. If so, then for those to whom it's not obvious why such programs would
  22. need to be ported, kernel data structures are probably *quite* different
  23. in Solaris 2.x, which is why programs that access those data structures
  24. directly will need to be changed.
  25.  
  26. (Note that programs that mainly just read the process table, and maybe
  27. process U areas, can, in Solaris 2.x, use the standard SVR4 "/proc" file
  28. system.  That will make them more likely to run under future Solaris 2.x
  29. releases, and under other SVR4 releases; it will also probably make them
  30. simpler, and possibly even less likely to fail in the fashion hinted at
  31. in the SunOS 4.x "ps" manual page:
  32.  
  33.     BUGS
  34.          Things can change while ps is running; the picture it  gives
  35.          is only a close approximation to the current state.
  36.  
  37. Things can still change out from under you, but "/proc" may make it
  38. less likely to happen.)
  39.  
  40. >or if the 
  41. >program access some of the system files that have changed (like /etc/fstab =>
  42. >/etc/vfstab), it will have to be ported.
  43.  
  44. Yup, this is a bit of a headache, as the "getmntent()" routine doesn't
  45. hide the name of the file.  SVR4 has "getvfsent()" to read
  46. "/etc/vfstab", and "getmntent()" to read "/etc/mnttab", and hides the
  47. file name.
  48.