This has got me to thinking about something I thought about when I first put
devfs/devfsd on my machine; using the "standard" way of doing things, if you
compile CDROM support as a module, then you won't have _any_ /dev entries
until after you have loaded that/those modules. If you later unload them,
the /dev entries stay around and will cause the modules to be reloaded if
you access them. This is good.
The problem is that the entries don't exist until after you have loaded the
modules the first time, which kind of defeats the purpose of having the
CDROM support as a module in the first place. The only workaround right now
is to set up your /etc/devfsd.conf file to force them to be loaded, but this
relies on you knowing where your CD-ROM drives are located on your IDE
busses, and thus compromises some of the elegance of using devfs in the
first place.
Has any thought ever been given to allowing each module to load, identify
the devices it can support that are currently attached to the machine,
register the appropriate devfs entries, then unload itself? There are some
obvious limits to this (it won't work for hot-plugged devices, for one), and
of course I could accomplish the same thing by manually loading/unloading
said modules in one of my init scripts, but again, this defeats the elegance
of devfs. If this just "worked", as the user expected, meaning that if your
machine has one or mode IDE CD-ROM drives attached, they would appear under
/dev/cdroms regardless of whether CD-ROM support was modular or compiled in,
this would make devfs much easier for users to deal with.
I realize, of course, that this would be quite a significant change to the
driver modules, and may not be possible at all, but I throw it out for
consideration regardless :-)
----- Original Message -----
From: "Richard Gooch" <rgooch@xxxxxxxxxxxxxxx>
To: "TGOS" <tgos@xxxxxxxx>
Cc: <devfs@xxxxxxxxxxx>
Sent: Friday, May 11, 2001 2:51 PM
Subject: Re: DEVFSD and modules - does it really work?
> tgos@xxxxxxxx writes:
> > Hello everyone,
> >
> > I only subscribed to that mailing list, because I'm a very curious
person and I
> > always have to know everything. ^_-
> >
> > Once I read about DEVFS, I simply had to try it.
> > I installed DEVFSD, recompiled the Kernel (v 2.4.2) and everything
worked fine.
> >
> > Except one problem:
> > My HDs are /dev/hgd and /dev/hdf (connected to my second IDE
controller).
> > Both had been there (thanks to DEVFSD), as well as under their new name.
> >
> > But my CDROM wasn't there anymore. It usually should be /dev/hda, but
neither
> > that, nor the new device names for the first IDE controller existed.
> >
> > I recompiled the kernel and found out that the CDROM support was set to
> > "module". After I compiled it into the Kernel, the device was there
(/dev/hda)
> > and I could use it.
> >
> > But since I don't use the CDROM pretty often, I usually compile CDROM
support
> > and the ISO9660 support as modules.
> >
> >
> > Here's my question:
> > I thought if I compile the CDROM support as module and later on load
> > that module, the DEVFS will add a new device and thanks to DEVFSD it
> > will also exist as /dev/hda
> > But it wasn't there.
> >
> > Is there any way to get it there or is the only chance compiling
> > CDROM support into the Kernel?
>
> I have all my IDE drivers as modules, and my IDE CD-ROM shows up just
> fine under /dev/ide. The modules I have loaded are:
> isofs 19600 0 (unused)
> ide-cd 27264 0
> cdrom 28416 0 [ide-cd]
> ide-probe-mod 9344 0
> ide-mod 64480 0 [ide-cd ide-probe-mod]
>
> with the bottom one loaded first.
>
> As a sanity check, look at your kernel logs and see if you get a
> message like:
> hdb: ATAPI 48X CD-ROM drive, 128kB Cache, DMA
>
> This is supposed to come from the ide-cd module, when it detects your
> CD-ROM.
>
> Regards,
>
> Richard....
> Permanent: rgooch@xxxxxxxxxxxxx
> Current: rgooch@xxxxxxxxxxxxxxx
>
>
>
|