| 1 |
Hello all, |
| 2 |
|
| 3 |
Here's a proposal I had after talking over with some kernel devs and |
| 4 |
plasmaroo (since he works on genkernel): |
| 5 |
|
| 6 |
[ Introduction ] |
| 7 |
|
| 8 |
One of the most painstaking process in installing any linux distribution |
| 9 |
is the kernel. Some create tools to automate the process, others make |
| 10 |
kernels that have support for *, and end up somewhat bloated. In seeing |
| 11 |
this as a major issue for people trying to switch over to linux, I |
| 12 |
decided to take a look at what could be done. |
| 13 |
|
| 14 |
[ Framework ] |
| 15 |
|
| 16 |
When one does `make modules_install` for the kernel, a special file is |
| 17 |
created called modules.pcimap. This file associates pci modules with |
| 18 |
pci id's. That said, if one compiles all modules, a complete map would |
| 19 |
be created (there is a command to do this.. can't remember off the top |
| 20 |
of my head). This file could be used by a program to reference back and |
| 21 |
forth with lspci and have only the modules built for only the currently |
| 22 |
installed pci devices. This would clear up a fair amount of effort in |
| 23 |
figuring out what module is needed for what device, a somewhat |
| 24 |
frequently asked question. |
| 25 |
|
| 26 |
[ Gentoo Usage ] |
| 27 |
|
| 28 |
By utilizing the file with a userspace program (let's say genkernel), |
| 29 |
the current livecd's could be improved as far as hardware detection in |
| 30 |
the kernel. A one time pass on the kernel would create the map, and it |
| 31 |
would be shipped with the livecd. This would also help the existing |
| 32 |
installer automation potential. |
| 33 |
|
| 34 |
[ Issues ] |
| 35 |
|
| 36 |
This does come with a few questions though: |
| 37 |
|
| 38 |
1) What if the device has no module? |
| 39 |
2) Do we generate it for a specific kernel version for the livecd, or |
| 40 |
try multiple ones? |
| 41 |
3) Do arches have any issues? |
| 42 |
4) Is it possible for two modules to hold over the same device and |
| 43 |
possibly conflict with each other? |
| 44 |
5) Could certain modules cause other modules to fail? Does a short |
| 45 |
rules list need to be created to prevent problematic combinations? |
| 46 |
6) How should we approach the userspace program? Should we simply |
| 47 |
extend genkernel or go with something more specialized? |
| 48 |
|
| 49 |
[ Conclusion ] |
| 50 |
|
| 51 |
So, that is the basic proposal I wish to set forth. I'd like to also |
| 52 |
make note that I noticed earlier there is a modules.usbmap as well, |
| 53 |
which could possibly go hand in hand with lusb to achieve the same effect. |
| 54 |
|
| 55 |
That's it, thanks ahead of time for comments/suggestions/etc. I hope |
| 56 |
this will progress things further and make kernel building a lot less of |
| 57 |
a pain. |
| 58 |
|
| 59 |
Chris White |
| 60 |
http://www.securesystem.info |
| 61 |
|
| 62 |
"The meaning of life is to attach an idea to the word life" |
| 63 |
-- |
| 64 |
gentoo-releng@g.o mailing list |
Archives