Sure. It is a tradeoff to split information. But I don't want that.
> I generate this list from the kernelsources by using a rather large
> perlscript. There are several different kinds of specifying PCI ids
> within the source, either in tables, or direct, by using for() loops
> and more.
> I do this for _every_ new patchlevel.
Iiik... Sounds like a pain in the ass to me.
> > To add new hardware ID:s to the driver and recompile would
> > sure work for you. And for me. I would do the same thing.
>
> The module has to be updated anyway, if the detection code has to
> detect new Ids.
The way it is handled today, yes.
I am very impressed to hear that someone had the guts to solve it
as it is today... You run into problems, right?
How do you solve multiple ethernet cards?
I want it the other way! No initialization in the driver at insertion-time!
No ID check in the driver at all. Maybe some kind of sanity check,
but the goal is to keep the driver without any knowledge about any ID:s.
Instead - A huge database with ID pairs, module name and
extra parameters.
Modules - Inserting - Theory of operation:
The PCI device info are exported to userspace as today. (/proc)
Some script reads it, scans the database and finds the entry.
If the driver isn't loaded - load it.
No init, scanning, probing should be done now.
Call the driver in some way to configure it and pass parameters
from /proc/bus/pci and the extra parameters in the database.
Then should the driver initialize the hardware pointed out by the
parameters.
Modules - Removing - Theory of operation:
In a similar way to configuration is de-configuration done.
If the de-configured device is the last one, remove driver.
Compiled-in drivers - Theory of operation:
The user runs some PCI scanning software that builds include files
from the device-database.
The experienced user might want to edit the includefiles.
The kernel is compiled.
Everything works. =)
> So by using one PCI id resource within the module itself, there is
> only one place to maintain.
Yes, sure. It _is_ bad to have two places to maintain.
But it seems like a big thing to patch the driver and recompile it
if the same thing could be acompished with adding the ID pair to the database.
In 2004 the drivers will be made of 100 lines ID:s...
> > But in the long run I think we must have some central database.
>
> Yes, but autogenerated from the kernelsourcetree!
Or.. the other way. =)
> I would suggest:
> - Add easy parsable pci ids to the modules.
> > Autogenerate a global list of IDs from the sourcecode and
> - Use usermode scripts to load the modules.
And, why not treat pcmcia and other hotinsertion stuff as USB in the same way?
Of course, this is only one idea how to solve the configuration problem.
But it would sure be nice with a autodetecting Linux. My grandma should use it!
Cheers /
magnus
-
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/