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]
Message-ID: <Pine.LNX.4.64.0709120339470.26177@localhost.localdomain>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ