[gentoo-releng] Automating the process of building kernel pci drivers

[gentoo-releng] Automating the process of building kernel pci drivers

[Chris White]

Hello all,

    Here's a proposal I had after talking over with some kernel devs and
plasmaroo (since he works on genkernel):

[ Introduction ]

One of the most painstaking process in installing any linux distribution
is the kernel.  Some create tools to automate the process, others make
kernels that have support for *, and end up somewhat bloated.  In seeing
this as a major issue for people trying to switch over to linux, I
decided to take a look at what could be done.

[ Framework ]

When one does `make modules_install` for the kernel, a special file is
created called modules.pcimap.  This file associates pci modules with
pci id's.  That said, if one compiles all modules, a complete map would
be created (there is a command to do this.. can't remember off the top
of my head).  This file could be used by a program to reference back and
forth with lspci and have only the modules built for only the currently
installed pci devices.  This would clear up a fair amount of effort in
figuring out what module is needed for what device, a somewhat
frequently asked question.

[ Gentoo Usage ]

By utilizing the file with a userspace program (let's say genkernel),
the current livecd's could be improved as far as hardware detection in
the kernel.  A one time pass on the kernel would create the map, and it
would be shipped with the livecd.  This would also help the existing
installer automation potential.

[ Issues ]

This does come with a few questions though:

1) What if the device has no module?
2) Do we generate it for a specific kernel version for the livecd, or
try multiple ones?
3) Do arches have any issues?
4) Is it possible for two modules to hold over the same device and
possibly conflict with each other?
5) Could certain modules cause other modules to fail?  Does a short
rules list need to be created to prevent problematic combinations?
6) How should we approach the userspace program?  Should we simply
extend genkernel or go with something more specialized?

[ Conclusion ]

So, that is the basic proposal I wish to set forth.  I'd like to also
make note that I noticed earlier there is a modules.usbmap as well,
which could possibly go hand in hand with lusb to achieve the same effect.

That's it, thanks ahead of time for comments/suggestions/etc.  I hope
this will progress things further and make kernel building a lot less of
a pain.

Chris White
http://www.securesystem.info

"The meaning of life is to attach an idea to the word life"
-- 
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Automating the process of building kernel pci drivers

[Daniel Drake]

Chris White wrote:
>     Here's a proposal I had after talking over with some kernel devs and
> plasmaroo (since he works on genkernel):

Kernel hackers have been thinking about this for eternities but have never
come up with a perfect solution.

Here's one problem I can see:

http://sosdg.org/~coywolf/lxr/source/drivers/ide/pci/amd74xx.c#L504

You can see in that table, that support for certain devices depends on the
CONFIG_BLK_DEV_IDE_SATA option. When you do your first-pass, presumably using
a config where every PCI-related option is selected, you'll get the amd74xx
driver providing support for those devices. Your script needs to be able to
detect that support for that particular device is *also* dependant on that
option, otherwise it wouldn't be selected when the users build.
[ This is ignoring the fact that there's another driver for this hardware in
the kernel. I'm sure there are other drivers which genuinely depend on certain
other config options for device support ]

Which brings up the next question, once the utility has figured out that I
need modules including snd-intel8x0, amd74xx, forcedeth, how is it going to
then deduce that the options required are CONFIG_SND_INTEL8X0,
CONFIG_BLK_DEV_AMD74XX and CONFIG_FORCEDETH?

Also, the clashing problem.. Drivers such as 8139cp and 8139too support the
same PCI devices, but you can't figure out which driver is useful until you
probe the hardware. It's usually safe to build both. But when you come to
other situations, such as sk98lin vs skge (almost identical device tables),
you are only ever going to want one or the other.

Daniel
-- 
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Automating the process of building kernel pci drivers

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Tue, 2005-04-19 at 12:24 +0900, Chris White wrote:
> 1) What if the device has no module?
> 2) Do we generate it for a specific kernel version for the livecd, or
> try multiple ones?
> 3) Do arches have any issues?
> 4) Is it possible for two modules to hold over the same device and
> possibly conflict with each other?
> 5) Could certain modules cause other modules to fail?  Does a short
> rules list need to be created to prevent problematic combinations?
> 6) How should we approach the userspace program?  Should we simply
> extend genkernel or go with something more specialized?

7) What if you bought the device after building your kernel?
8) What if the device is external and not connected?
9) Why are we even bothering with this?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]