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