From: Chris White <webmaster@securesystem.info>
To: gentoo-releng@lists.gentoo.org
Subject: [gentoo-releng] Automating the process of building kernel pci drivers
Date: Tue, 19 Apr 2005 12:24:02 +0900 [thread overview]
Message-ID: <426479D2.1010206@securesystem.info> (raw)
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
next reply other threads:[~2005-04-19 3:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 3:24 Chris White [this message]
2005-04-19 7:19 ` [gentoo-releng] Automating the process of building kernel pci drivers Daniel Drake
2005-04-19 13:08 ` Chris Gianelloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=426479D2.1010206@securesystem.info \
--to=webmaster@securesystem.info \
--cc=gentoo-releng@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox