Dagmar d'Surreal dagmar.wants at
Fri Feb 27 10:27:24 PST 2004

On Thu, 2004-02-26 at 19:02, Albert wrote:
> On Thu, 26 Feb 2004 11:23:45 -0600
> "Dagmar d'Surreal" <dagmar.wants at> wrote:
> > On Wed, 2004-02-25 at 19:13, Albert wrote:
> > > I have always before compiled everything I needed into the kernel,
> > > so have not been bothered with a modules.conf file.  Now, I find
> > > myself wanting to understand how modules work.  I have read the man
> > > page and a couple of HOW-TOs, but am still in the dark on several
> > > really basic points.   I can get the module names from /lib/modules,
> > > but just where do the alias_names come from?  The man page says that
> > > the modules.conf file is optional. So when is it required?
> > > 
> > > In this link: 
> > >
> > > it says:
> > > "If you are maintaining one system and memory is not in short
> > > supply, it is probably easier to avoid modprobe and the various
> > > files and directories it needs, and just do raw insmods in a startup
> > > script." Which startup script(s) would that be?  Does anyone here do
> > > this?
> > 
> > That is absolutely terrible advice, and horribly out of date as well.
> As you will note, the link is to The Linux Documentation Project and is
> dated January this year.  Why is it terrible advice?  And how is it out
> of date? This is also mentioned in the Cd Writing HOWTO that you
> recommend in another post.

Using insmod directly is hackish and deprecated.  Modprobe assumed all
it's functionality long ago and is the proper way to avoid bad things
like double-loading of unintelligent modules.  Furthermore, kmod was
invented so we no longer don't have *do* that insmod nonsense, and if it
can be used, it should.  These tools were put into the system to make
life easier in the eyes of kernel developers and woe shall befall any
who resists the will of kernel devs and still tries to use their kernel.

Don't get it into your head that the stuff on TLDP is perfect.  It's a
better documentation source than most things on the internet, but many
of those documents were written by people without the benefit of much
clue and will occasionally be dead wrong.  With respect to telling
people to use insmod, this is about as close to dead wrong as one can
get without telling people to install a pizza into the CPU slot.  Kmod
deprecated the use of modprobe years ago, and modprobe deprecated the
use of insmod years before that.  This guy might as well be telling
people to use gcc directly to compile things and read the Makefiles to
figure out which source files to compile and in what order.  If you know
exactly what you're doing, insmod _can_ still be used because there are
occasions when it's needed (rare though they may be) but doing so
requires you have any options to pass to the module availalble right
then and there and that you know exactly what's going to happen in all
instances where insmod is being invoked--which is way more effort than
is generally needed.

...and re-read my earlier post.  I said the ignore directive was
_mentioned_ in the CD-Writing HOWTO.  I didn't recommend it, by which
you seem to imply I'm endorsing it.  Regardless of it's utility, someone
researching how to use a CD burner should definitely have read at least
_some_ documentation before asking questions of a mailing list, and I
(as well as most) tend to think of that as the most obvious thing in the
world for someone interested in learning how to use their CD burner (as
opposed to someone interested in having someone tell them how to use
their CD burner) to have read by now.

> > If module loading is _that_ much of a problem for you, 
> Do you have issues with me?  Or are you just snippy with everyone?  I
> said above that I am learning.  And, no, it's not a problem because I
> can get around it.  But I would like to understand it anyway.

With the advent of kmod, module loading should have become an
"occasionally poke at and forget about it" operation.  If what you're
doing with modules takes a lot of work, you're probably ignoring kmod,
and making extra work for yourself.

Do you have martyr issues?  If you're doing a lot of _work_ to make your
modules function, you're not doing it the right way.  It is generally
easier to hand off worrying about this stuff to hotplugd and get on with
more important things than it is to even bother thinking about which
specific drivers need to be loaded for say, your PCI ethernet card.  

> > install hotplugd and it should eliminate >90% of it.
> How so?  I could find no home page for a product "hotplugd."  I always
> understood hotplugging to mean plugging/unplugging devices on a running
> machine and I have no hotpluggable devices. Most likely I misunderstand
> that also. 

You did.  Hotplugd (as I have said on this list many times before) flat
out eliminates the majority of module loading issues by scanning the
various buses and loading the modules for every identifiable device it
finds.  With usbmodules and pcimodules installed as they suggest, this
means every PCI card and every USB device that is supported is almost
certain to get it's rrespective module loaded and require no
administrative effort at all on your part (all in all, probably a better
driver loading solution than Win32 is ever likely to get).

/sbin/hotplug is invoked _by the kernel_ when a new device (*) appears
on a bus, and generally aims to deprecate a lot of the kmod
functionality.  With this in mind--insmod deprecated by modprobe, and
modprobe invocation deprecated by kmod--it should become fairly obvious
why telling someone to load everything with insmod directly is refusing
to acknowledge about a half-dozen _years_ of development.

(* For these purposes, the first time the kernel sees devices after the
bus driver is loaded is the exact same thing, and is referred to as
cold-plugging since the hardware was installed and present when the
machine was off.)

> > As to the rest of it,
> > it's always seemed to me that the kernel devs made it up as they went
> > along (which is being corrected in the 2.6 series).
> What's different in 2.6?  I haven't looked at it.

That's been discussed on these lists before recently as well.  The names
(like sound-slot-0 and such) associated with devices, up until now, were
assigned more or less at the whim of the driver authors.  There's a
shift in design with 2.6 to turn those device names into something
that's _also_ configurable and tied to unique numbers assigned to each
piece of hardware so that they can actually be changed.

> > Tell us what
> > class of device you're trying to get modules to load for (specifically
> > which device) and we'll be happy to tell you what we know.  Generally
> > everything comes down to one or two lines in /etc/modules.conf. 
> In /lib/modules/2.4.24 I have:
> drivers
> 	block
> 		floppy.o
> 	cdrom
> 		cdrom.o
> 	char
> 		lp.o
> 	parport
> 		parport.o
> 		parport_pc.o
> 	scsi
> 		ide-scsi.o
> 		scsi_mod.o
> 		sg.o
> 		sr_mod.o
> 		sym53c8xx.o
> fs
> 	ext2
> 		ext2.o
> 	ext3
> 		ext3.o
> 	jbd
> 		jbd.o
> scsi emulation is for a SONY CD-RW CRX216E

This one last line was all that needed to be mentioned.  The default
behaviour for the kernel with respect to IDE CD drives is to assign
control of them to ide-cd.  You can stop this one of two ways... One is
to assign control of the particular drive to ide-scsi using the
hd?=ide-scsi argument, and the other is to tell ide-cd to ignore hd?
(once again, with a kernel boot argument) but you'll _still_ need to
assign ide-scsi control of hd? (which is most easily done with a kernel
boot argument).

When the kernel boots and inits the IDE bus, it will at that time
attempt to assign something to handle each device on the bus.  If you've
built ATAPI cdrom support into your kernel, it's going to become the
handler of your drive whether you like it or not unless you tell it
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at

More information about the blfs-support mailing list