[openbeos] Add-ons/Module problems/ideas??
- From: Timothy Covell <timothy.covell@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 30 Jul 2002 23:58:02 -0400
I am listening to the audio from the Linux symposium in Ottawa this year. The
module presentation is quite interesting because, to me, it shows how much
better OpenBeOS should be able to do this, especially with its concepts of
bus managers and userland add-ons. [Caveat: I was not at the conference, so
I cannot know what transpired in the after talk chats.] At one point Rusty
Russell(?) suggests that Linux get rid of modules all-together. That
astounded me because under Linux:
1. It's impossible to boot a PC with a static kernel which is 7.5 MB in size.
Indeed, AFAIK, this was the reason why modules were created in the first
place.
2. It is quite common that I have to unload a kernel module and reload it.
For example, the SBP-2 driver needs to be reloaded to ensure that my devices
are recognized (due to hot plug problems). A member of the audience
(Linus??) makes reference to PCMCIA (16 bit) problems that require module
reloads.
3. If I change the layout/tree/sequence of the bus/chain of my hot swappable
devices, how do I ensure that they come up at the same address? Namely, if I
plug in a new device, will /dev/sda become /dev/sdb on reload or reboot? I
still have nightmares about SCSI problems that we had with devices coming
up with the wrong addresses. Fibre Channel, when done correctly, is supposed
to fix this, but can be troublesome. If I don't like the a particular
layout, I can remove the module, rearrange my devices, and reinsert the
module, the aim being to recover my prefered device assignments.
4. Without modules, I cannot add a new driver without reboot; that is way too
much like Micro$oft for me! (At one point in the presentation, someone
suggested that one only allow module loading at boot time, which is exactly
what Micro$oft and others do.) But this is how system add-ons are handled
on BeOS isn't it?
5. Without module reloading, it becomes very difficult to do debugging of
module/addon code.
6. What if I insert a module, decide that it is buggy, and want to remove it??
Anyhow, my questions to the OpenBeOS community are:
Does anyone else here card about these issues?
Is the BeOS 5.0.3 implementation of addons good enough for OpenBeOS R1?
Doesn't everybody here want a kernel that blows Linux out of the water
(excluding drivers which must come from 3rd parties)?
Just some questions.
P.S. I seem to have misplace the URL for the audio, but I can forward the
few ogg files that I downloaded to anyone who needs them. Don't bother
listening to the AMD presentation given by some AMD bloke; the Hammer/x86-64
article at aceshardware.com is much better. [I was astonished however by
the engineers reliance on the Andrea Arcangeli and the Linux community's
work on Linux on Hammer for debugging and even _implemenation_. He
said that the SMP v. CC-NUMA aspects of Hypertransport would be more clearly
defined after further testing by Andrea!]
P.P.S. If any Linux folks read this, please take a few classes in public
speaking! Even RMS knows how to give a presentation, even if he doesn't
always make a good choice concerning his material (like being pro-drugs) ;-).
--
timothy.covell@xxxxxxxxxxxx
Unix Systems Administrator
Other related posts:
