lkml.org 
[lkml]   [1999]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Putting PCI-class/vendor/deviceinfo into source of PCI-drivers
Hello!

> modules.dep is not the right place for these. What we need is an auto
> generated module alias file. Add these lines to /etc/modules.conf, or
> better still make them the default for modprobe.
>
> if -f /etc/modules.conf.auto
> include /etc/modules.conf.auto
> endif
>
> The above syntax is a modutils 2.3 feature. /etc/modules.conf.auto is
> program generated from the drivers and contains lines like this
>
> alias pci-0200-115d-0003 tulip_cb
> alias pci-0200-115d-1181 serial_cb
>
> It does not matter if the driver is a module or builtin, the aliases
> are built for all pci combinations. Building for modules is easy, for
> built in drivers is harder.

Who is expected to generate the modules.conf.auto file?

> > o If a new device gets inserted, the kernel looks up its ID in all currently
> > loaded drivers and asks them if they want to handle the device.
>
> Not sure that is a good idea. It requires extra table comparison code
> in every driver and we already have the external mapping from pci codes
> to module.

It requires _global_ table comparison code which will simplify PCI probing
in most drivers (see also the recent PCI helper by Donald Becker for an
example of how this can be done).

Also, external mapping from PCI codes to module is a good idea, but it should
be generated automatically from the drivers themselves since to avoid having
to modify it each time you change your kernel.

> It would be better to add an ioctl to every driver which
> kmod or modprobe could call to say "you are registered for device c-v-d
> and it just got inserted/deleted".

It wouldn't work well since you would need to know how to obtain a file
descriptor for each driver and there are even drivers creating no such
descriptors (parport driver, USB low-level driver et cetera).

Better make that an internal kernel call-back.

> > o If no driver is found and kmod is enabled, modprobe gets called to find
> > a driver corresponding to the device ID according to modules.dep and load
> > the appropriate module.
>
> Call modprobe for all insert or deletes. It will load the module if
> not already loaded using the auto generated aliases then call the
> "device inserted" ioctl. If already loaded or builtin (the latter is
> the tricky bit), just call the ioctl.

How do you recognize built-in drivers?

> Whatever happens, we need a consistent interface. It must work for
> modules (easy) and builtin (how do we identify them?) drivers. And it
> must be able to cope with two or more copies of the same module loaded
> under different names (messy).

Do we really need that? I think that all hot-plug drivers should be able
to handle multiple devices without having to resort to such ugly tricks.
(Hmmm, it comes to my mind that we have to solve passing of options somehow...)

Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/
"return(ENOTOBACCO); /* Read on an empty pipe */"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.136 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site