home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.xenix.sco
- Path: sparky!uunet!wupost!gumby!destroyer!mudos!mju
- From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
- Subject: Re: Adaptec 1740 modes.
- Message-ID: <BtxpqL.1qC@mudos.ann-arbor.mi.us>
- Date: Wed, 2 Sep 1992 04:56:43 GMT
- References: <9209010953.AA25837@dynamix.com>
- Organization: The Programmer's Pit Stop, Ann Arbor MI
- Lines: 93
-
- In article <9209010953.AA25837@dynamix.com> david@dynamix.com (David L Jarvis) writes:
- >well for someone who spent a couple of hundred lines telling me how
- >atrocious my correspondence skill are, I'd have to say that "Aiiieee!"
- >ranks right up there with AIN'T ...
-
- I also sent that to you in e-mail, because spelling flames are not
- appropriate for general Usenet consumption.
-
- Ever hear of "humor?" Or "conversational English?"
-
- >(but nice try at the cheap shot tho, you're getting better with each try)
-
- Huh? All I implied that your memory might be somewhat less than
- perfect, and that you might have mistranscribed something if you
- copied it from memory. This is a cheap shot?
-
- >ANYONE on the net - check it out for yourself!!! Call SCO or get SCO
- >magazine and verify it ... (repeated for those of you who failed to read
-
- I wouldn't call SCO Magazine a source of gospel about SCO Unix. The
- second-line and third-line support technicians at SCO are generally
- more trustworthy (the first-line technicians, unfortunately, do the
- same thing I could do myself -- look up my problem in the SCO
- Information Tools database).
-
- >so how about it Marc, again I'll challenge you, give SCO a call and ask
- >them what they suggest for making the change ... and then post the response
- >you get ...
-
- Well, I haven't called SCO SofTech yet, mostly because I have real
- work to do, and my real work consists of answering questions for
- paying customers, instead of answering questions for the net. But if
- I get a free moment I'll see about calling them.
-
- >(what Marc said doesn't make sense to me, because anyone who knows the
- >system would know that eiad is just the enhanced mode of the ad driver, so
- >I see no confusion there, but I'm open to discussion on it)
-
- The problem is that, the way the ID system is set up, each device
- driver is supposed to have system-dependant information about the
- driver configuration (IPL level to run at, IRQ lines used, I/O
- addresses used, and so forth) in /etc/conf/sdevice.d/name_of_driver.
- i.e., the sio driver info is in /etc/conf/sdevice.d/sio, the ad driver
- info is in /etc/conf/sdevice.d/ad, and so forth. When idbuild is run,
- it concatenates all of the files in /etc/conf/sdevice.d into a master
- /etc/conf/cf.d/sdevice file.
-
- The idea is that each driver can be installed, deinstalled, and
- modified in a modular way without modifying files that the other
- drivers know about. There's none of the ugliness associated with the
- Xenix link_xenix shell script, or with BSD-style kernel configuration.
-
- The "correct" way to turn a driver off is to change the second field
- of its sdevice file from a Y to an N. Similarly, the correct way to
- turn a driver on is to change the second field from an N to a Y. You
- are not supposed to add entries to an sdevice file for drivers other
- than the one with the same name as the sdevice filename.
-
- Now, let's say that you do things SCO's way, and change the instances
- of "ad" to "eiad" in /etc/conf/sdevice.d/ad. The next time you build
- your kernel, the ad sdevice file will get concatenated with all the
- other files in /etc/conf/sdevice.d, including
- /etc/conf/sdevice.d/eiad, which is where the eiad-related
- configuration is *supposed* to go. Since SCO ships SCO Unix with the
- eiad driver turned off, there will be no problems; the idbuild script
- doesn't know where the individual lines in the sdevice file came from,
- and so it won't notice that there is no "ad" line and that there are
- two "eiad" lines, since the second one is disabled.
-
- However, let's now say that you get an SLS from SCO that includes a
- new "ad" driver. Let's say that this driver fixes a problem with the
- Adaptec driver preempting another driver because the Adaptec driver
- was running at the wrong IPL level. To change the IPL level, you have
- to modify the sdevice file; most likely, the SLS will overlay your
- existing "ad" sdevice file with the new one. This is completely
- legal, since the SLS isn't changing any other drivers -- or is it?
- Since you put the eiad sdevice info in the ad sdevice file, you've now
- lost your eiad sdevice info.
-
- If, on the other hand, you put the sdevice info for the eiad driver
- where it belongs -- in eiad's sdevice file -- you will have no
- problems.
-
- >well your .sig sure gives us some insight into YOUR computing philosophies
- >tell me, you would happen to be a college student would you?
-
- Nope. Actually, I'm a senior in high school. But what does my age
- have to do with this?
-
- --
- Marc Unangst | Real men don't use Windows. Real men use X.
- mju@mudos.ann-arbor.mi.us | Only a real man would use a GUI where the
- | shift keys after "Alt" are "Super" and "Hyper."
-