J Scott Berg (jsberg@indiana.edu)
Mon, 1 Feb 1999 10:26:21 -0500 (EST)
On Mon, 1 Feb 1999 grant@torque.net wrote:
> > 1) If your rc scripts run depmod, comment that out. The alternative
> > is to write a ed script which is run after depmod which does what
> > follows.
>
> No.
Is that "No" a reaction to what follows or a reaction to commenting
out depmod in the startup scripts. I've never seen the need to run it
every time I reboot.
> > 2) Run depmod manually after each kernel build. This is a bit tricky;
> > you should run it once after you've built the kernel but before you've
> > rebooted, using an explicit version number (this will get most
> > everything right); then you need to do it again after you've rebooted
> > with the new kernel (to catch a couple ones that didn't get taken care
> > of). Again, if you are clever you can probably automate this in your
> > startup scripts.
> > 3) There's a file that's created by depmod called
> > /lib/modules/<version>/modules.dep. In there you'll find
> > makefile-style dependencies. You need to add a dependency for pcd.
> > You'll see that it already has a dependency for pcd, which is paride.
> > To that same line, add the full path to the epat module. Now,
> > 'modprobe pcd' should work.
>
> All of this nonsense can be avoided with the "pre-install" feature of
> modprobe.
The problem with the pre-install feature is that (from the man page)
Note that the pre- and post-remove commands will
not be executed if a module is "autocleaned" by
kerneld!
That's the reason I go through "all of this nonsense." I hot-swap a
printer and a tape backup on the parallel port. Of course, kmod in
the new kernels doesn't autoclean anyhow.
> > 4) Now to get it recognized automatically. Make sure pcd is
> > unloaded. If you attempt to access the device, the module still won't
> > be loaded. But if you examine your log files (syslog/messages),
> > you'll see it complaining that it
> > 'can't load module char-major-46' or some such nonesense (sorry,
>
> How about "block-major-46" ?
Yeah, that would make much more sense (I do this with a tape drive, so
char-major is stuck in my head).
> > I'm not at the machine where I've done this before, otherwise I'd tell
> > you exactly what it is). The important thing is the
> > 'char-major-46' or whatever it is. Take that, and alias it in your
> > conf.modules to pcd:
> >
> > alias char-major-46 pcd
> >
> > Question: why doesn't this happen automagically like with other
> > drivers? Or does it, just not in the 2.0.x kernels?
>
> It's nothing to do with the kernel. The userland tools need to know
> about block-major-46. Talk to the maintainers.
Ah. Learned something today.
> > Now when you try to access the device, it should automatically load
> > it. Be sure not to run depmod automatically any more! Otherwise step
> > 3 will get clobbered.
> >
> > Driver writers: it would be really groovy if pcd asked for a
> > "pcd_lowlevel" or something and we could alias that to whatever in the
> > conf.modules, so the module dependencies didn't have to be rewritten
> > all the time. I'm insufficiently driver-savvy to know if this is
> > possible or what it involves (or at least to be able to figure it out
> > in some reasonable amount of time).
>
> See above.
Well, this one is a bit different. Think about the 2.2 parport
driver. It seems to have some mechanism for asking for
parport_lowlevel, which everyone then aliases to parport_pc. That
doesn't seem to be part of the modutils. This was what I was thinking
of.
-Scott Berg
-- J. Scott Berg Phone: (812) 855-5465 Indiana University Cyclotron Facility FAX: (812) 855-6645 2401 Milo B. Sampson Lane email: jsberg@indiana.edu Bloomington, IN 47408-1398-- To unsubscribe, send mail to: linux-parport-request@torque.net -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Mon 01 Feb 1999 - 10:26:56 EST