From: Takashi Iwai <tiwai@suse.de>
To: "Chris Li" <lkml@chrisli.org>
Cc: "Giacomo A. Catenazzi" <cate@cateee.net>,
"Mauro Carvalho Chehab" <mchehab@infradead.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org
Subject: Re: diet-kconfig: a script to trim unneeded kconfigs
Date: Tue, 23 Sep 2008 13:31:09 +0200 [thread overview]
Message-ID: <s5hr67bumiq.wl%tiwai@suse.de> (raw)
In-Reply-To: <70318cbf0809221225i5be0ce6eh3ac09d8bf61cc2d7@mail.gmail.com>
At Mon, 22 Sep 2008 12:25:21 -0700,
Chris Li wrote:
>
> On Mon, Sep 22, 2008 at 3:01 AM, Takashi Iwai <tiwai@suse.de> wrote:
>
> > I think a whitelist would be useful, too, e.g. for hotplug devices
> > like usb.
>
> The white list is marginally useful. But it is very complicate to do.
> In order to preform white list. You have to know the dependency
> of the module. e.g. You need to know exactly which options to
> turn on so the modules will show up. The current dependency
> analyze is the other way around. It knows which device should
> show up when some config option is enabled. Answering the
> question of which option should enable in order that device
> show up is a much harder problem.
That is true. Enabling arbitrary kernel config item is hard to
achieve right now. I think this feature should be implemented in
kbuild parser itself. The current reverse-select is way limited and
known to be problematic in many kernel configs.
Anyway, I think the white list isn't that hard for certain use-cases.
My assumption is that users base on the distro kernel that have
already all modules. Then, for likely scenarios such as USB-storage
hotplug, we can simply provide possible modules such as usb-storage
and nls_* as the additional modules. The script would just need to
add them to the existing module list. If necessary, the module
dependency can be solved easily from modules.dep, too.
> Also, as long as the user can get a boot able kernel out of
> the minimal config. It is easy enough to recompile the kernel
> with white list modules and install them as needed.
I don't think choosing necessary kernel config is "easy enough". If
it were easy enough, we don't need such scripts at all. The problem
is that you must know exactly which config should be used for what
purpose. This is often a high hurdle.
> The white list should be a secondary step to do because
> its complexity. The first priority is to have some thing simple
> and provide a good minimal kernel module option. Then we
> can go from there, how to add extra white list from it. The white
> list is a very different game any way. I found the minimal config
> option is a sweet spot to have in terms of feature and simplicity.
I feel you goal is much farther than mine :)
The white list can be just a list of modules. If it doesn't work,
that's fine -- at least, we get the exactly same system like currently
running.
> > This should be fixed in Makefile.
> > Care to submit a patch?
>
> Some module does not want to be compile as build-in.
But not about this case. It wants to be compiled-in, too.
thanks,
Takashi
next prev parent reply other threads:[~2008-09-23 11:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-16 23:55 diet-kconfig: a script to trim unneeded kconfigs Takashi Iwai
2008-09-18 14:01 ` Giacomo A. Catenazzi
2008-09-18 20:09 ` Takashi Iwai
2008-09-18 15:25 ` Mauro Carvalho Chehab
2008-09-18 15:43 ` Giacomo A. Catenazzi
2008-09-18 16:27 ` Mauro Carvalho Chehab
2008-09-19 9:12 ` Giacomo A. Catenazzi
2008-09-19 16:01 ` Takashi Iwai
2008-09-19 23:55 ` Chris Li
2008-09-19 23:57 ` Chris Li
2008-09-22 10:01 ` Takashi Iwai
2008-09-22 13:39 ` Giacomo A. Catenazzi
2008-09-22 15:41 ` Steven Rostedt
2008-09-22 15:50 ` Takashi Iwai
2008-09-22 19:25 ` Chris Li
2008-09-23 11:31 ` Takashi Iwai [this message]
2008-09-23 18:15 ` Chris Li
2008-09-23 18:50 ` Takashi Iwai
2008-09-23 19:40 ` Chris Li
2008-09-18 20:20 ` Takashi Iwai
2008-09-18 20:17 ` Takashi Iwai
2008-09-18 21:09 ` Valdis.Kletnieks
2008-09-18 22:14 ` Takashi Iwai
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=s5hr67bumiq.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=cate@cateee.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@chrisli.org \
--cc=mchehab@infradead.org \
--cc=rostedt@goodmis.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