Linux-Development-Sys Digest #138, Volume #7 Wed, 1 Sep 99 21:14:26 EDT
Contents:
understanding scheduling in Linux ("Surya P Kommareddy")
Re: understanding scheduling in Linux (Kaz Kylheku)
Re: Disabling control-alt-delete from a program (Victor Wagner)
Re: TAO: the ultimate OS (Peter da Silva)
Re: Disabling control-alt-delete from a program (Olaf Klischat)
Re: TAO: the ultimate OS (Kaz Kylheku)
Re: PROPOSAL: A secure, simple NIS replacement (David T. Blake)
Re: Jesus: the ultimate OS ("Christopher R. Thompson")
Re: PCI card question (Andomar)
Re: TAO: the ultimate OS (Philip Brown)
Re: PROPOSAL: A secure, simple NIS replacement (David T. Blake)
Re: GGI vs. framebuffer (Tristan Wibberley)
Re: TAO: the ultimate OS (Peter da Silva)
PCI card question (zackary)
Re: NFS caching (bill davidsen)
Mouse ("Milan Hampl")
Re: threads ("Bill Burris")
Re: TAO: the ultimate OS (Peter Samuelson)
Re: SCSI device scan order. (bill davidsen)
----------------------------------------------------------------------------
From: "Surya P Kommareddy" <[EMAIL PROTECTED]>
Subject: understanding scheduling in Linux
Date: Wed, 1 Sep 1999 15:56:20 -0700
Hi,
I am beginning to program modules under Linux (version 2.0.36). I would
like to know some pointers to information on the scheduling implimentation
inside the Linux kernel and the function calls available for assigning
priorities etc. Also please inform me how to assign real-time priority to a
process and how these real-time processes are scheduled by the kernel. Any
help is appreciated.
Thanks in anticipation.
Surya.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: understanding scheduling in Linux
Reply-To: [EMAIL PROTECTED]
Date: Wed, 01 Sep 1999 23:11:32 GMT
On Wed, 1 Sep 1999 15:56:20 -0700, Surya P Kommareddy <[EMAIL PROTECTED]> wrote:
>Hi,
> I am beginning to program modules under Linux (version 2.0.36). I would
>like to know some pointers to information on the scheduling implimentation
Read kernel/sched.c
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: 1 Sep 1999 22:09:28 +0400
In comp.os.linux.development.apps [EMAIL PROTECTED] wrote:
: [EMAIL PROTECTED] (Lew Pitcher) wrote:
:>Remove this line, and you have disabled the <ctl><alt><del> keysequence.
:>Change the line to run a different program (say
:> ca::ctrlaltdel:/bin/echo 'somebody hit ctl-alt-del' >/dev/console
:>and you change the action the key sequence invokes
: Yeah , I know about inittab, but I'm specifically looking to be enable and
: disable it from certain programs. Like I said , XF86 can do it so their must
: be some system call buried in libc or similar to be able to do it.
No, this is other way around - X server takes completely over the
console, including keyboard, and just not let keypress pass to kernel
code which triggers appropriate line in inittab. Note that Alt-Fn
sequences are disabled altogether, and X server implements its own
Ctrl-Alt-Fn instead.
So, if you are not going to take over console completely, best thing you
can do is to edit inittab and replace call to shutdown by call to some
script, which checks some flag, set by program (for instance, some file
in /var/lock) and if flag is up, doesn't let user to shutdown.
Thus program doesn't need to be setuid root. It just need to have enough
privilegies to set the flag.
: NJR
--
========================================================
Victor Wagner @ home = [EMAIL PROTECTED]
I don't answer questions by private E-Mail from this address.
------------------------------
From: [EMAIL PROTECTED] (Peter da Silva)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 23:24:03 GMT
In article <7qk02t$[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
> unix is not easy for the nonliterate user to handle. quite to
> the contrary I would say it is "nonliterate hostile".
Western society as a whole is "nonliterate hostile", and attempts to
make it less so rarely work. If you want a computer for people who can't
read or write, I recommend you look towards Nintendo and Sega.
--
In hoc signo hack, Peter da Silva <[EMAIL PROTECTED]>
`-_-' Ar rug t� barr�g ar do mhact�re inniu?
'U` << <KH> you did technical support for Hell ?
<susan> Didn't we all, in our youth? >:) >>
------------------------------
From: Olaf Klischat <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Disabling control-alt-delete from a program
Date: 02 Sep 1999 01:40:39 +0200
Emile van bergen <[EMAIL PROTECTED]> writes:
> On 1 Sep 1999, Olaf Klischat wrote:
>
> >"Ben Gunter" <[EMAIL PROTECTED]> writes:
> >
> >> In /etc/inittab, there's a line like this:
> >>
> >> # Trap CTRL-ALT-DELETE
> >> ca::ctrlaltdel:/sbin/shutdown -t3 -r now
> >>
> >> I think commenting that line out and running "init q" will have the effect
> >> you're looking for.
> >>
> >
> >Hmm.. not that I have much of an idea about linux system programming,
>
> What does this example have to do with programming? 'If it ain't
> clickety-click, it's programming'???
Is there a misunderstanding here?
The original poster said that what he wanted to do was "Disabling
control-alt-delete from a _program_". Which, in this case, would mean
to do all these inittab modifications "silently" via fread()/fwrite()
or something directly from the program.
OK, maybe that's not so much a problem with inittab as it would be
with, say, /etc/profile, because inittab has a fairly fixed format,
but nonetheless...
I for myself wouldn't want to have my config files modified by
something other than myself (that is, my favorite text editor :)
). Isn't it "common sense" in unix to _edit_ configuration files
manually or maybe with some authorized configuration tool only? If you
don't follow that rule, there's always the chance that you break
something, IMVHO.
>
> >but sometimes I come to the conclusion that, in the unix world, it is
> >considered sane to hack some rather sensitive config file
> >programmatically and be happy that it works somehow...
>
> It's a _configuration_ file, for $DEITY's sake, just like you said! It
> is _meant_ to be edited to suit your particular setup/situation!
>
> And the use of 'hacking' instead of editing is just to make it sound
> bad. What exactly do you mean? The above is not a trick of some sort, is
> is documented and well-defined behaviour.
>
> And text files are a lot less sensitive than a binary heap full of
> pointers, IMHO. hdfsSetKeyRegExA(), wouldn't you call that
> 'programmatically hacking a rather sensitive config file?'
>
Indeed I would, at least as long as it would be used to edit something
other than the invoking program's own registry sections.
just my 0.01..
Olaf
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Wed, 01 Sep 1999 23:31:56 GMT
On 1 Sep 1999 23:24:03 GMT, Peter da Silva <[EMAIL PROTECTED]> wrote:
>In article <7qk02t$[EMAIL PROTECTED]>,
>Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>> unix is not easy for the nonliterate user to handle. quite to
>> the contrary I would say it is "nonliterate hostile".
>
>Western society as a whole is "nonliterate hostile", and attempts to
>make it less so rarely work. If you want a computer for people who can't
>read or write, I recommend you look towards Nintendo and Sega.
Hey, books are nonliterate hostile too. Let's burn them all!
;)
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: 1 Sep 1999 18:26:13 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > That's why NIS+ exists.
> > What's so tough about typing
> >
> > "nispopulate -F passwd"
> > after you add a user?
> > There is basically no additional maintainance after you get it set up,
> > if all you want to do is "a secure /etc/passwd distribution mechanism"
>
> 1. NIS is not secure.
> 2. NIS does not allow me to arbitrarily string clients/servers so that I
> can build up a user database in a heirarchy (NIS+ does this, but is even
> more footprint-intensive than NIS.
>
> I may just have to write the damn thing, since no one seems to
> understand why it's interesting. As a UNIX sysadmin on-and-off of
> 10 years, I know that *I* would want this thing!
You are not alone. The SRP group at Stanford is working on a
replacement, and they have a good security algorithm that
fulfills most of what you'd need for an NIS replacement. They
could use some more hackers. Their licensing is rational. They
patented the algorithm, and will allow anyone to use it as long
as you don't sell it. If you sell it you have to license the
patent and pay them for it.
They say they merely want the patent to be fully freely
useable so that Internet security does not rely on commercial
vendors. But they need hackers for the NIS replacement
project. They have good working versions of ftp and telnet
already.
http://srp.stanford.edu/srp/
I am not affiliated with them, but could really use
a secure NIS replacement.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: "Christopher R. Thompson" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: Wed, 01 Sep 1999 16:31:48 -0700
Stuart Fox wrote:
>
> Christopher R. Thompson <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Stuart Fox wrote:
> > >
> > > There is also plenty of evidence that the whole religion is based on
> > > Egyptian religion. But you knew that because you've researched this
> > > thoroughly?
> >
> > I'm not really interested in Egyptology all that much. Is there
> > something importatnt that I should be aware of?
>
> Just that many of the Egyptian traditions were assimilated into the
> Christian faith. Interestingly enough, the Christianity of today was mostly
> started by the writings of Paul, not the teachings of Jesus. Could that be
> why there's so much shit in the name of Christianity?
>
I'm sorry to disagree. I believe it started with Moses. Which I'm sure
you already know was raised Egyptian. Would you say passover was an
Egyptian tradition?
> >
> > > Have a look at all the books that didn't make it into the Bible because
> they
> > > didn't toe the party line.
> >
> > Would you post the books on the Internet. I don't have access to them.
>
> They've been published in one form or another (mostly), with plenty of
> analyses. Anything which discusses the real dead sea scrolls, or the
> "gnostic scriptures" should cover all the bits that were left out.
To much controversy remains on the dead sea scrolls, with limited or
non-existant access to Non-'whoever controls'-access personages.
I've probably heard of gnosticism but you are the first person EVER to
tell me I should study it. Do you know why the bits were left out?
------------------------------
Date: Thu, 02 Sep 1999 01:36:41 +0200
From: Andomar <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,redhat.general
Subject: Re: PCI card question
You really want to post this to a linux.install
or linux.setup or linux.sound sorta newsgroup.
People who monitor these might actually be of
help to you :)
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: 01 Sep 1999 23:20:45 GMT
On 30 Aug 1999 18:00:51 -0300, [EMAIL PROTECTED] wrote:
>...
>Please explain this sandbox of yours in detail. What exactly would
>a program be barred from doing? To keep a virus from infecting other
>programs, you'd have to bar all programs from being able to open
>any file, which would make it impossible to install new programs if
>all programs were constrained to the sandbox.
>
>To prevent filesystem corruption (which would ultimately cause OS
>corruption), you'd have to make it completely impossible to directly
>access a filesystem. This would create a problem for filesystem checkers.
Anyone who even wants to run a filesystem checker in a "sandbox" is an idiot.
But that's not the idea behind a sandbox. A sandbox is to check user-level
programs.
A filesystem checker is NOT a user-level program. It is a system level
program. If you accept system-level programs from non-trustable sources,
you are also an idiot.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
--------------------------------------------------
The word of the day is mispergitude
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: 1 Sep 1999 23:35:23 GMT
Reply-To: [EMAIL PROTECTED]
Peter T. Breuer <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> : [EMAIL PROTECTED] wrote:
> : > On Wed, 25 Aug 1999 14:43:01 GMT, [EMAIL PROTECTED] wrote:
>
> : 1. NIS is not secure.
>
> And so what? I have never understood this hooha. If somebody really
> wants to spend his time cracking user passwords instead of asking me
> for a login, good luck to them. And there are far easier ways to get
> passwords than cracking public encryptions. Just monitor the net for
> pop3 from windows machines, for a start!
It gets a little more complex than that for various reasons.
Suppose you administer a network for a large research center
than has some 500 users some of whom are littered across the
globe. Then suppose some little twerp IP spoofs your NIS
server and grabs the password file. What are the odds crack
will find at least one bad password ? Unless you've been
administering the network for some time and forcing bad
passwords from users to change them in person, the twerp is
in like Flynn.
So you run crack against your own users, and you find 10
bad passwords. Unfortunately, 5 of them are in Israel, Sweden,
and the opposite coast of the US. You lock them out and you are
fired for obstructing their research (the whole reason your
job exists).
You desperately need some form of encryption for the research
center other than hashed password files.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: GGI vs. framebuffer
Date: Thu, 02 Sep 1999 21:54:24 +0100
Reply-To: [EMAIL PROTECTED]
"J�rgen Hermanrud Fjeld" wrote:
>
> Hi!
>
> In order for Linux to be a games platform, hardware acceleration in relation
> to graphics is necessary. Having read a little about GGI it seems this
> architecture will support hardware acceleration for graphics adapters, whereas
> the fb architecture apparently won't. Is this correct, and if that is the case,
> why not skip the entire fb project and implement the KGI part of GGI into the
> kernel?
Get ready for a flamefest :)
The issues are more complicated.
The framebuffer console is in use by many peices of software - though
there is less and less software that *requires* it as they move to more
abstracted methods of controling the graphics hardware such as libGGI,
ClanLib, CrystalSpace.
The old version of KGI (KGI 0.0.9) was really a proof of concept, a
first try to see what stuff was really needed. The name of KGI was not
helped by the idiots that kept telling the Linux kernel developers to
include it even in it's early development.
The new version of KGI (KGI 0.9) requires more changes to the linux
console than the kernel developers wanted, although it has become clear
that the console needs to be improved, and it is being improved. When
the standard console does (nearly) all the things that KGI 0.9 needs,
KGI becomes a simple display device for fbcon, just like fbdev will be.
At this point, the simple framebuffer drivers will (probably) become
obsolete quickly as gamers and power users require the flexibility that
KGI provides, and KGI also can be limited to what framebuffer drivers do
- as the user requires.
In the future, I expect to see the linux implementation of KGI look like
the standard vga console from the outside as long as you use vga text
mode only. This would mean that you would simply compile your kernel
with the vga driver in at boot (or VBE2 fixed mode framebuffer for some
notebooks), and can insert the module for your hardware when you want
it. This would mean that the standard kernel source would only need a
few drivers for boot up - which I believe Linus (and many others
including me) would prefer.
In short: Soon, the linux implementation of KGI will have nothing
against it that fbcon doesn't have against it, and will have many things
for it. At that point, no smart person would not want to have it in
Linux - unless they said "never" and their pride in their arguments is
more important than their pride in their software (and there aren't many
like that at all - which is why Linux has become so good). But at the
moment there are real practical issues that mean you can't just plug it
into todays kernel and call it stable.
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (Peter da Silva)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 14:58:38 GMT
In article <7qiqic$7jg$[EMAIL PROTECTED]>,
Peter T. Breuer <[EMAIL PROTECTED]> wrote:
> The chroot and limit resources idea doesn't lock one out of the
> rest of the machine. There are plenty of globals left. Such as block
> raw block devices! Tcp/ip. Etc.
I once proposed to as a security enhancement a flag that, when turned on,
disabled raw disk access, sockets, system V shared memory, and all the other
out-of-filesystem namespaces when in a chrooted environment.
--
In hoc signo hack, Peter da Silva <[EMAIL PROTECTED]>
`-_-' Ar rug t� barr�g ar do mhact�re inniu?
'U` << <KH> you did technical support for Hell ?
<susan> Didn't we all, in our youth? >:) >>
------------------------------
From: zackary <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,redhat.general
Subject: PCI card question
Date: Wed, 01 Sep 1999 23:31:04 GMT
hello guys
I would like to know why PCI sound card not supported by linux (I'm using
linux redhat 6.0). Why only scsi slot sound card widely supported as
nowdays its
hard to find scsi slot sound card on sales. I ask the shop which
sells pre installed
linux in their pc about the sound card.
And I would like to know are pci slot vga
card supported by linux.
Pls guide me. I'm quite despair when my PCI sound card
undetected by
linux. I could hear no sound.
Thank you.
-azaria-
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.networking
Subject: Re: NFS caching
Date: 1 Sep 1999 19:32:51 GMT
In article <[EMAIL PROTECTED]>,
H.Bruijn <[EMAIL PROTECTED]> wrote:
| On 31 Aug 1999 19:48:35 GMT, bill davidsen allegedly wrote:
| >Has anyone done anything to reduce network traffic between client and
| >server when the data on the server is known not to change? I'm being
| >very vague because I don't want to scare off any good solutions.
| >
| >What I'd like to do is set aside a GB or so of local disk as a cache
| >area for that data which is known not to change. Unfortunately I need a
| >"per mount" solution, since there are other mount points which change
| >normally.
| >
| since the data on the server is known not to change, and the clients
| have sufficient disc space, just copy the data from the server to the
| clients. Then when the data on the server does change, use rsync to
| update the data on all clients with a simple script.
No, the clients don't have remotely enough disk to hold the data, or I
would do the copy. The main data set consists of hundreds of GB of data,
and I would like to cache the LRU data on the client, since the recently
written bits are most heavily used. Since the files are large and only
records will be used, partial caching would be nice.
I'd rather not write an interface layer which is application dependent,
since there are already several applications which have similar needs to
access portions of a very large database.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"So let it be written, so let it be dumb." Pharaoh Dufus the last...
------------------------------
From: "Milan Hampl" <[EMAIL PROTECTED]>
Subject: Mouse
Date: Wed, 1 Sep 1999 15:50:31 +0200
Please, excuse me to send my nessage to the wrong group. So I installed Red
had 6.0 with PS2 mouse, next time HDD device with installed system was
removed to another (similar) computer. This computer has only serial mouse.
I am sure that some possibility to change it without reinstallation exists,
but at linuxconf does not. Plese advice me.
======================================================================
Milan Hampl
IKA PRAHA v.o.s. stredisko IKADATA
tel.:+4202 67313002, fax: +4202 673125858
e-mail: [EMAIL PROTECTED], http://www.ika.cz
-----------------------------------------------------------------------
------------------------------
From: "Bill Burris" <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Tue, 24 Aug 1999 14:44:21 -0600
Randall Parker <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> I find the whining of Unix programmers about threads to be kinda like
> baby duck syndrome. What, I have to learn something about an API that
> didn't first show up on Unix and that Unixes competitors have been
> touting as an advantage for years? Well, given that Unix isn't going to
> be getting VMS's queued IO model then kernel level threading is, IMO, the
> next best thing.
>
The book I just read claimed that the first complete implementation of
Threads was in Mach, developed at CM. Steve Jobs had the chance to provide
some competition for Microsoft but he destroyed his company producing groovy
hardware instead of realizing that Mach and the software they built around
it was the ticket to success.
Would Linux gain anything by having its kernel replaced by Mach?
Bill
--
http://www.icrossroads.com/~spider
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 18:38:32 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Theodore Y. Ts'o <[EMAIL PROTECTED]>]
> > The limitations of sandboxes are also well known; either you make
> > the sandbox too limiting, in which case you can't do anything
> > interesting, or you make the sandbox too big, in which case the
> > virus or other hostile code can do too much damage.
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> I think this is a false dichotomy. I think when a designer runs into
> this quandary it reflects a lack of imagination & engineering
> ingenuity.
Whom are you accusing of lack of imagination or engineering ingenuity?
Not to imply that he's some sort of inerrant god, but in a Linux
newsgroup Ted T'so brings a lot of credentials to the table. He has
designed and built a lot of the stuff in Linux you use every day -- not
by dreaming, not by "spreading the memes", but by actually working.
When he says it's been done, that it involves tradeoffs and that you
can't just hand-wave those away, I think I'll take his word for it over
yours. Have you actually tried implementing a sandbox architecture?
How did *you* use your superior imagination and engineering ingenuity
to overcome the problems he outlines?
> > For example, all user applications can't just run in a sandbox,
> > because they need access to the user's data files. So if you have
> > hostile code embedded in a Microsoft Word macro, for example, the
> > fact that it's running in a sandbox won't help you. You could
> > restrict things so that an application only has access to its own
> > data files --- i.e., a word processor has access to only its own
> > word processor files, and a spread sheet only has access to its
> > file. But now you can't embedded a spreadsheet in a word processor
> > document!
> I just pointed out in a recent message..its obvious you can have some
> files that are read only to some applications, and write to others.
> what you are telling me is that it could become slightly more
> complicated than an existing system. but this is quite different
> than the claim of impossibility.
He didn't say "impossible", he said there are tradeoffs. Security
versus ability to do anything useful. If you don't want your system to
do anything useful, you can secure it real tight.
> yes, that is exactly what I am proposing: a system in which all
> applications run in a sandbox-- even key elements such as drivers. I
> believe this is not only desirable but inevitable.
As another poster said already, applying the concept of a sandbox to
things like device drivers is simply adopting a microkernel
architecture. In other words it's about as old and tired as the rest
of your revolutionary ideas.
> let us agree on this then:
> the problems will not go away unless the sandbox is designed in an
> ingenious way that transcends all prior attempts lacking in
> imagination.
OK, but you've been arguing the inverse, i.e. the problems *will* go
away when you *do* design the sandbox in an ingenious way that
transcends all prior attempts lacking in imagination. A claim you most
likely can't back up without actually showing us an actual new,
ingenious sandbox design that shows promise of tackling some of these
issues.
> let us also agree that while such a thing may perhaps be difficult to
> achieve, it certainly is not going to create itself.
Odd, that's what we've all been telling you this whole time. You seem
to think that your OS *will* create itself if you just talk about it
long enough. We say talk is cheap, very cheap. Are you a PHB, by any
chance? Because sometimes you sound like one. You do need to pick up
more of the lingo, though. Learn to use phrases like "thinking outside
the box" and "rethinking paradigms".
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.help,comp.os.linux.setup
Subject: Re: SCSI device scan order.
Date: 1 Sep 1999 20:08:28 GMT
In article <[EMAIL PROTECTED]>,
Seth Mason <[EMAIL PROTECTED]> wrote:
| My system is setup to boot off of /dev/hda which resides on the NCR
| internal scsi adapter, and I use the qlogic adapter to for external high
| speed storage. My problem is, the kernel appears to load the driver for
| the qlogic adapter first and then the NCR scsi adapter. This is a
| problem, b/c the kernel then tries to mount root off of the qlogic
| adapter and not off of the NCR scsi adapter.
Say what? The boot device, /dev/hda, is not a SCSI deveice. Hopefully
you meant /dev/sda and don't type any better than I do.
I don't think the kernel is loading the drivers at all, because the
driver for the boot disk has to be in the kernel at boot time. And if
the other driver were a module that would definitely be loaded after and
that would leave sda as the boot device. that said, I don't believe you
are loading any drivers, I think they are both built into the kernel.
Stop me if I've missed something on that.
So the only issue is that the controllers are being probed in the wrong
order, which is a bit easier to solve. You have three possible
solutions. first, you may be able to fix this with an append= line in
LILO, forcing the order by specifying scsi0 and scsi1. I don't know how
to do that off the top of my head, but you can look it up and try it "by
hand."
Okay, the second, brute force, works every time approach is to build the
driver for the internal controller into the kernel, and the other
controller as a module. That should work just fine.
Finally, since "what's in a name" is true with Linux, you can change the
names in /etc/fstab to match the way the kernel comes up, and change
lilo.conf to use the names the way they "want to be" and not touch your
kernel.
One of these solutions will work, probably all of them.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"So let it be written, so let it be dumb." Pharaoh Dufus the last...
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
