linux-kernel - stripping down the kernel-parameters.txt file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Sep 2007 03:50:17 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: stripping down the kernel-parameters.txt file

  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
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/