home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / xenix / sco / 2790 < prev    next >
Encoding:
Text File  |  1992-09-01  |  4.9 KB  |  104 lines

  1. Newsgroups: comp.unix.xenix.sco
  2. Path: sparky!uunet!wupost!gumby!destroyer!mudos!mju
  3. From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
  4. Subject: Re: Adaptec 1740 modes.
  5. Message-ID: <BtxpqL.1qC@mudos.ann-arbor.mi.us>
  6. Date: Wed, 2 Sep 1992 04:56:43 GMT
  7. References: <9209010953.AA25837@dynamix.com>
  8. Organization: The Programmer's Pit Stop, Ann Arbor MI
  9. Lines: 93
  10.  
  11. In article <9209010953.AA25837@dynamix.com> david@dynamix.com (David L Jarvis) writes:
  12. >well for someone who spent a couple of hundred lines telling me how
  13. >atrocious my correspondence skill are, I'd have to say that "Aiiieee!"
  14. >ranks right up there with AIN'T ... 
  15.  
  16. I also sent that to you in e-mail, because spelling flames are not
  17. appropriate for general Usenet consumption.
  18.  
  19. Ever hear of "humor?"  Or "conversational English?"
  20.  
  21. >(but nice try at the cheap shot tho, you're getting better with each try)
  22.  
  23. Huh?  All I implied that your memory might be somewhat less than
  24. perfect, and that you might have mistranscribed something if you
  25. copied it from memory.  This is a cheap shot?
  26.  
  27. >ANYONE on the net - check it out for yourself!!!   Call SCO or get SCO
  28. >magazine and verify it ... (repeated for those of you who failed to read
  29.  
  30. I wouldn't call SCO Magazine a source of gospel about SCO Unix.  The
  31. second-line and third-line support technicians at SCO are generally
  32. more trustworthy (the first-line technicians, unfortunately, do the
  33. same thing I could do myself -- look up my problem in the SCO
  34. Information Tools database).
  35.  
  36. >so how about it Marc, again I'll challenge you, give SCO a call and ask
  37. >them what they suggest for making the change ... and then post the response
  38. >you get ...   
  39.  
  40. Well, I haven't called SCO SofTech yet, mostly because I have real
  41. work to do, and my real work consists of answering questions for
  42. paying customers, instead of answering questions for the net.  But if
  43. I get a free moment I'll see about calling them.
  44.  
  45. >(what Marc said doesn't make sense to me, because anyone who knows the
  46. >system would know that eiad is just the enhanced mode of the ad driver, so
  47. >I see no confusion there, but I'm open to discussion on it)
  48.  
  49. The problem is that, the way the ID system is set up, each device
  50. driver is supposed to have system-dependant information about the
  51. driver configuration (IPL level to run at, IRQ lines used, I/O
  52. addresses used, and so forth) in /etc/conf/sdevice.d/name_of_driver.
  53. i.e., the sio driver info is in /etc/conf/sdevice.d/sio, the ad driver
  54. info is in /etc/conf/sdevice.d/ad, and so forth.  When idbuild is run,
  55. it concatenates all of the files in /etc/conf/sdevice.d into a master
  56. /etc/conf/cf.d/sdevice file.
  57.  
  58. The idea is that each driver can be installed, deinstalled, and
  59. modified in a modular way without modifying files that the other
  60. drivers know about.  There's none of the ugliness associated with the
  61. Xenix link_xenix shell script, or with BSD-style kernel configuration.
  62.  
  63. The "correct" way to turn a driver off is to change the second field
  64. of its sdevice file from a Y to an N.  Similarly, the correct way to
  65. turn a driver on is to change the second field from an N to a Y.  You
  66. are not supposed to add entries to an sdevice file for drivers other
  67. than the one with the same name as the sdevice filename.
  68.  
  69. Now, let's say that you do things SCO's way, and change the instances
  70. of "ad" to "eiad" in /etc/conf/sdevice.d/ad.  The next time you build
  71. your kernel, the ad sdevice file will get concatenated with all the
  72. other files in /etc/conf/sdevice.d, including
  73. /etc/conf/sdevice.d/eiad, which is where the eiad-related
  74. configuration is *supposed* to go.  Since SCO ships SCO Unix with the
  75. eiad driver turned off, there will be no problems; the idbuild script
  76. doesn't know where the individual lines in the sdevice file came from,
  77. and so it won't notice that there is no "ad" line and that there are
  78. two "eiad" lines, since the second one is disabled.
  79.  
  80. However, let's now say that you get an SLS from SCO that includes a
  81. new "ad" driver.  Let's say that this driver fixes a problem with the
  82. Adaptec driver preempting another driver because the Adaptec driver
  83. was running at the wrong IPL level.  To change the IPL level, you have
  84. to modify the sdevice file; most likely, the SLS will overlay your
  85. existing "ad" sdevice file with the new one.  This is completely
  86. legal, since the SLS isn't changing any other drivers -- or is it?
  87. Since you put the eiad sdevice info in the ad sdevice file, you've now
  88. lost your eiad sdevice info.
  89.  
  90. If, on the other hand, you put the sdevice info for the eiad driver
  91. where it belongs -- in eiad's sdevice file -- you will have no
  92. problems.
  93.  
  94. >well your .sig sure gives us some insight into YOUR computing philosophies
  95. >tell me, you would happen to be a college student would you?
  96.  
  97. Nope.  Actually, I'm a senior in high school.  But what does my age
  98. have to do with this?
  99.  
  100. -- 
  101. Marc Unangst                | Real men don't use Windows.  Real men use X. 
  102. mju@mudos.ann-arbor.mi.us   | Only a real man would use a GUI where the
  103.                             | shift keys after "Alt" are "Super" and "Hyper."
  104.