I've never understood how you manage kernel modules at boot time

Robert P. J. Day rpjday-L09J2beyid0N/H6P543EQg at public.gmane.org
Mon Feb 25 19:51:57 UTC 2008


On Mon, 25 Feb 2008, Mike Oliver wrote:

> Quoting Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>:
> >
> > If you have a static /dev directory, then you might have something like
> > this:
> >
> > crw-rw---- 1 root video 195,   0 2008-02-17 10:39 /dev/nvidia0
> >
> > This character device has majpr 195 and minor 0.  So if you try to open
> > it, and the kernel goes "No driver is handling that major/minor right
> > now, so I will ask modprobe for help".
> >
> > modprobe then sees an alias that says anything with major 195 on a
> > character device should load something named 'nvidia' so it loads the
> > module nvidia and returns to the kernel.  Hopefully the nvidia module
> > then loaded and now provides a driver for the character device 195,0 and
> > the original request can proceed, otherwise the kernel returns -ENODEV
> > to the program trying to open /dev/nvidia0.
>
> OK, this is some help, thanks; I'll look at my /dev directory when I
> get home.  But I still don't understand the sequence of events.  I
> *don't* try to open /dev/nvidia0; it's some script at boot time that
> does that, I suppose (or would if I used nVidia), but I don't know
> which script or how to find it.  Grepping through the various
> /etc/rcN.d/ directories is tedious and has not historically seemed
> to turn up what I'm looking for, quite possibly because I don't
> *know* what I'm looking for.

  by the time you get to trying to "open" a device file like
/dev/nvidia, everything underneath has already been set up.  that
device file will have a major and minor device number, and those two
values will map to some kernel code that is already registered at
those values.  let's look at an example:

  kernel source, file drivers/media/video/videodev.c:

...
#define VIDEO_NAME              "video4linux"
...
static int __init videodev_init(void)
{
        int ret;

        printk(KERN_INFO "Linux video capture interface: v2.00\n");
        if (register_chrdev(VIDEO_MAJOR, VIDEO_NAME, &video_fops)) {
                printk(KERN_WARNING "video_dev: unable to get major %d\n", VIDEO_MAJOR);
                return -EIO;
	...

  taking my word that VIDEO_MAJOR is defined as the value 81, what the
code above does at load time is try to allocate the major number 81
for a character device.  if that works, then you'll get this line
in /proc/devices as verification:

 81 video4linux

all that's telling you is that major number 81 for char devices is now
allocated to the kernel name "video4linux" -- it *hasn't* created a
special device file that corresponds to it yet.  however, if you look
under /dev, it's clear that there's a /dev file for it:

  $ ls -l /dev/video0
  crw-rw----+ 1 root root 81, 0 2008-02-24 07:57 /dev/video0

so where did that device file come from?  good question -- i'm
guessing /etc/udev/rules.d/50-udev-default.rules:
...
# video4linux
KERNEL=="vbi0",                 SYMLINK+="vbi"
KERNEL=="radio0",               SYMLINK+="radio"
KERNEL=="video0",               SYMLINK+="video"
...

  does that clear things up a bit?

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list