An interesting idea for you techies

Rob Wehrli rwehrli@azpower.com
Sat, 25 Nov 2000 22:38:22 -0700


Jason wrote:
> 
> Why not? After all, what better way to sell hard disks with faster
> seek times and higher rotation speeds than to add a whole bunch of

What about systems without hard disks?

> unnessary disk access by splitting what was once one file into a

There you go assuming disk access again.  I'm guessing that your only
experience with Linux is in a more "traditional" platform
environment...especially if you're having trouble figuring out why
modules are a *good* idea...and for more reasons than it came in the
jewel case.

> shitload of smaller files, and then passing this deed off with the
> claim that it makes it "easier".

So, why, Mr. Know-it-all, do you think kernel modules are the "standard"
rather than the "rarity?"  Why do installation CDs and accompanying boot
disks use them so prevalently?  Doesn't it make it easier for at least
installation of a new system; regardless of your feelings about what
constitutes a new system?

Since 1992 I've been deeply involved with Linux.  This is not to say
that I know everything about it, no, far from it.  It changes so rapidly
that I often fail to keep up with its pace.  However, there is one thing
that is certain and that is that those who believe that only those
persons using Linux with some superior gift for awk or sed should use
it, is complimentary to stupidity.  Since every single possible user in
the world is different, please quit foolishly imposing your views of
what is right on an entire audience.  Either share your views in a way
that adds your comments in an unimpossing way, or find an appropriate
chat room where foul language and abbreviated sentance structure is
common.

> 
> The only way its easier is if your one of those people who runs the
> kernel you got in whatever box you bought (or CD you installed from).

What if you're debugging a new device driver, huh, hotshot?  A complete
kernel recompilation sounds a bit foolish now, huh?  Not just a whole
lot more headache, but really, really *not* easier, huh?  What happens
if you're building a custom platform, but you do not yet know which
devices are going to be installed into the platform?  Say something less
abstract, like a notebook computer, since I can tell that you're likely
to have way too much interference between your skull and gray matter to
comprehend a significantly more complex thought.  Let's say that you've
just written a brand new device drirver (after 1152 kernel compilations
to debug it!) and now you want to send your driver and the new PCMCIA
device your company produces out into the field.  You include a CD or a
floppy disk, your PCMCIA neatly packaged in a piece of cool plastic that
has your company logo on it and your instruction booklet (written in
"your" poor grammar choices) firstly tells the user to recompile his/her
kernel now.  Oops, let's be sure that we do that everytime you reboot
but leave the PCMCIA card at home or decide that the two slots on your
laptop are not big enough for the four different cards you regularly
use.

I hope that I've taken an opportunity to *insult* your intelligence
enough for you to realize that the view of the world through just your
eyes is a fairly narrow field of vision.  It was through the vision of
many others that Linux has grown up to become a viable platform for more
than just spitting "Hello, World!" out of a serial port.  Use caution
when asserting your opinion as the only option available and making
others' opinions sound like bad dishwater.

> If your capable of recompiling the kernel, your system WILL boot
> faster if you avoid all the module shit. Basic laws of physics there.
> 

I may have slept through too many physics classes to know the
difference, but I'm guessing that you're suggesting with more code to
load, more time to execute it?  There are compromises made in nearly
every possible situation dealing with computing.  The balance of those
compromises strive to serve the good of a greater number, which is
possibly an entire thesis on supply-and-demand economics.  The real
power of Linux is that it gives you a choice.  For those who have
nothing better to do than sit around and ensure that they knock 5
seconds off their boot time by spending 30 minutes recompiling and 10
minutes picking their selections, there are those who figure that if
they reboot their computers only 479 times, then they'll have at least
beat your "performance record" by 5 seconds.  Pay me now or pay me
later; hey, it works for Java :)

Can you offer a better than "physics" response to the module load time
versus static kernel access time when all accesses occur from a flash
file system?  What happens to accesses when the flash is compressed? 
Does the thread that copies files to system RAM (SDRAM in the case of my
particular device design) and uncompresses the modules on the fly cost
me more usable system memory when I create a static kernel or is it
better for me to simply keep everything as a module?  Now through power
management into the equation...oooh boy, fun, huh?  Let's see now, what
happens to my kernel when PM wants to shutdown a device, but not the
entire system?  Can I just unload the module and quitely reload it again
later if needed?  Or, should I just say forgetabout the batteries, I'm
keeping everything up and running my entire life and if the user only
sees two hours between recharges, well, by God, he better start thanking
me for allowing him that much!

> One thing that *is* good about modules, however, is the fact that you
> can "reset", in a way, certain parts of the kernel, allowing you to
> get away with things not normally advisable. For example, if you boot
> from IDE, you can unload the SCSI module, and then pull devices off or
> put devices on your SCSI bus, then simply reload the module and avoid
> a reboot. The truly daring can boot from SCSI and do the same with IDE
> (warning, plug the cable in straight and power up the drive first,
> some drive will attempt to suck voltage THRU the IDE cable if not
> powered up, generally causing a reboot or worse, motherboard failure).
> They can also be extremely useful for someone attempting to get a
> given driver to work with an improper piece of hardware by modifying
> the source to the driver.
> 
> In a box that isnt subject to these non-production conditions, modules
> just slow things down. Odds are, by the time you are ready to change
> the hardware, you ought to download, configure and compile a new
> kernel anyways.

Odds are that by the time I re/boot 480 times to *tie* your performance
in compiling a new kernel, *I* will have bought new (most of my hardware
is old, dual Pentium/Pro/II, dual Sparc and Alpha junk that is at least
2-3 years old!) hardware (you're back to assuming Linux is just an x86
OS, even if you're going to deny it), too.  You know the time when I
really do spend time to compile a "decent" kernel?  It is on a Linux box
that I know must stay up for several months at a time.  It is in cases
as these that make the best sense to strip out all of the "crap" that
you won't need, since it is likely to be used in a relatively
single-purpose or at least high-availability role.  Plain-ole Linux
workstations, who cares?  Most of the time I'm compling kernels using a
cross version of the compiler anyway.  In my source tree, they compile
in about 5 minutes, give or take a bit, when building kernel debug
versions.  My development workstations use whatever run of the mill
kernel keeps the shell afloat and the hard drive spinning.  Most of my
work is from a remote X session from an NT box, too!  (gasp!)  I'm
currently writting a book on embedded Linux programming, however, even
that doesn't make me feel like I really know all that much about it. 
There is simply too much for any one person to know.  So rather than
shoving your opinion out there like the rest of us just SUCK, take a
moment to reflect on the many ways that one might use a tool as mighty
as Linux.  Try not to be shallow and try to use good judgement in
composing messages so that they do not overly reflect your obtuse ways
of thinking by use of "gutter mouth."  You'll find that an open mind is
a better approach when dealing with Linux...after all, it isn't supposed
to be a religion!

Take Care Jason.  I'm looking forward to your comments on this and
future topics.  Sorry to any other Pluggers who may feel as if I've
invaded their personal living space a bit more than just a little OT.  I
really do have a bunch of real questions that need answers in building
my device.  If anyone is interested in helping to solve them, let me
know.  If anyone read this far down, well, that is quite an
accomplishment, too! :)

Rob!