From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: stripping down the kernel-parameters.txt file
Date: Wed, 12 Sep 2007 03:50:17 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0709120339470.26177@localhost.localdomain> (raw)
while killing some time between compiles and ridding the
kernel-parameters.txt file of out-of-date or incorrect cruft, it
occurs to me that that file is borderline valueless since it
apparently tries to document every possible boot-time parameter,
including those associated with individual modules. that's just
silly.
it would make far more sense if that file restricted itself to just
those parameters that you'd consider fundamental or basic -- those
defined with one of "__setup()" or "early_param()" that would apply to
most users.
instead, you find stuff like this (a random example):
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
bttv.pll= See Documentation/video4linux/bttv/Insmod-options
bttv.tuner= and Documentation/video4linux/bttv/CARDLIST
not to belittle the bttv module but, really, is that information
worthy of being recorded in the top-level parms.txt file? and if
you're going to be consistent, you'd want to do that for every single
module and its respective throughout the tree, at which the parms.txt
file collapses under its own weight from forever being updated and has
so much information that it's impossible to find the useful stuff.
i suggest that that file record only the basic boot-time params, and
the documentation for module-specific parameters be moved closer to
the module source itself. there's no point in that poor file trying
to keep up with all of the module development in the tree.
rday
p.s. and, while we're at it, folks might like to start replacing
the calls to "__setup()" in their driver code with the newer module
parameters mechanism. it's just a thought. :-)
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
next reply other threads:[~2007-09-12 7:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 7:50 Robert P. J. Day [this message]
2007-09-12 12:43 ` David Newall
2007-09-12 13:11 ` Robert P. J. Day
2007-09-12 13:32 ` David Newall
2007-09-12 14:06 ` Robert P. J. Day
2007-09-12 14:30 ` Rogan Dawes
2007-09-12 14:44 ` Robert P. J. Day
2007-09-12 17:47 ` Kyle Moffett
2007-09-12 17:56 ` Randy Dunlap
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=Pine.LNX.4.64.0709120339470.26177@localhost.localdomain \
--to=rpjday@mindspring.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®