From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
Date: Fri, 25 Jan 2013 13:47:05 -0500 [thread overview]
Message-ID: <CAGfcS_kWQHLJ8uWYSJiM5CprM93MVKgzejcfhS6Lt2qVWidSLQ@mail.gmail.com> (raw)
In-Reply-To: <874ni5nmtb.fsf@ist.utl.pt>
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
> Is there any syntax to check if something is either disabled or built as
> a module?
Very problematic. What is built in for the currently running kernel
can be fairly reliably determined by grepping /proc/config.gz - IF
support for that was enabled in the kernel. But, there is no
guarantee that this kernel will be running on the next boot.
Determining what is build as a module really requires interpreting the
contents of /lib/modules - a module could have been built after the
kernel was built, in which case /proc/config.gz might indicate no
support even though it is supported. I don't think DEVTMPFS can be
made a module, however (not sure on that).
You can also check /usr/src/linux/.config, but the sources might not
correspond to the running kernel, or the kernel on the next reboot, or
whatever.
It really is a touchy situation, hence all the emails in the thread.
You can build something that will work OK 80% of the time though by
checking the source tree.
Part of me wonders if we should just ship a binary kernel/initramfs as
an option. Then again, users could just use genkernel and get
something like that anyway. My main issue with genkernel is that its
default options are focused more on the install CD than ordinary use -
things like tuners/multimedia/lirc and the like tend to not be
enabled. I would think a typical desktop-oriented distro is going to
enable as a module anything that doesn't cause breakage.
Rich
next prev parent reply other threads:[~2013-01-25 18:47 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 3:38 [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default Robin H. Johnson
2013-01-22 3:45 ` Mike Gilbert
2013-01-22 3:56 ` Zac Medico
2013-01-22 4:10 ` Rick "Zero_Chaos" Farina
2013-01-22 4:14 ` Zac Medico
2013-01-22 9:22 ` Markos Chandras
2013-01-22 14:49 ` Zac Medico
2013-01-22 4:23 ` Mike Gilbert
2013-01-22 6:22 ` Sergey Popov
2013-01-22 6:44 ` [gentoo-dev] " Duncan
2013-01-22 14:51 ` [gentoo-dev] " Zac Medico
2013-01-22 18:40 ` Robin H. Johnson
2013-01-23 12:32 ` Fabio Erculiani
2013-01-23 12:50 ` Rich Freeman
2013-01-23 21:27 ` Fabio Erculiani
2013-01-23 23:17 ` Francesco Riosa
2013-01-24 1:10 ` Robin H. Johnson
2013-01-24 19:46 ` Fabio Erculiani
2013-01-22 11:11 ` vivo75
2013-01-22 11:56 ` Rich Freeman
2013-01-24 17:04 ` Dustin C. Hatch
2013-01-24 17:49 ` [gentoo-dev] " Duncan
2013-01-24 18:09 ` Rich Freeman
2013-01-24 18:18 ` Ian Stakenvicius
2013-01-24 18:24 ` Dustin C. Hatch
2013-01-24 18:25 ` Rich Freeman
2013-01-24 18:55 ` Michael Orlitzky
2013-01-24 18:58 ` Ian Stakenvicius
2013-01-24 19:05 ` Rich Freeman
2013-01-24 19:21 ` Michael Orlitzky
2013-01-24 20:26 ` vivo75
2013-01-24 20:39 ` Michael Orlitzky
2013-01-24 20:45 ` Michael Orlitzky
2013-01-25 0:29 ` vivo75
2013-01-25 0:37 ` Michael Orlitzky
2013-01-24 21:30 ` Rich Freeman
2013-01-26 10:34 ` Fabio Erculiani
2013-01-26 22:25 ` Duncan
2013-01-26 22:30 ` Fabio Erculiani
2013-01-26 22:54 ` Rich Freeman
2013-01-27 0:31 ` Peter Stuge
2013-01-27 1:06 ` Rich Freeman
2013-01-25 1:39 ` Duncan
2013-01-25 1:53 ` Robin H. Johnson
2013-01-25 2:22 ` Michael Orlitzky
2013-01-25 3:12 ` Rich Freeman
2013-01-25 3:27 ` Michael Orlitzky
2013-01-25 6:15 ` Duncan
2013-01-25 18:24 ` Nuno J. Silva
2013-01-25 18:47 ` Rich Freeman [this message]
2013-01-25 19:19 ` Christopher Head
2013-01-25 19:26 ` Rich Freeman
2013-01-25 19:47 ` Nuno J. Silva
2013-01-25 19:57 ` Rich Freeman
2013-01-25 20:06 ` Nuno J. Silva
2013-01-25 20:31 ` Rich Freeman
2013-01-26 1:51 ` Duncan
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=CAGfcS_kWQHLJ8uWYSJiM5CprM93MVKgzejcfhS6Lt2qVWidSLQ@mail.gmail.com \
--to=rich0@gentoo.org \
--cc=gentoo-dev@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