linux-kernel - how about a massive reorg of the "Kernel hacking" submenu?

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>] [day] [month] [year] [list]

Date:	Sat, 26 Jul 2008 09:18:54 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...shcourse.ca>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: how about a massive reorg of the "Kernel hacking" submenu?

  this bit of whining is inspired by the observation that the "Kernel
hacking" submenu (at least under x86) has become ridiculously long and
seems only partially ordered by topic.  so some thoughts.

  first, rename it from "Kernel hacking" to "Kernel debugging" since,
well, pretty much *everything* you can do with "make *config" can be
considered "hacking" so that submenu title isn't particularly
informative.  and once that's done, really make it related to
exclusively debugging selections, which has some implications.

  first, debugging content from elsewhere should be shifted under
here, such as "kprobes" and "markers" which currently reside under
"General setup," which seems a bit odd.  and perhaps all
profiling-related selections could be moved here as well.  (BTW, is
"Profiling support" really still EXPERIMENTAL?  just curious.)

  at the same time, some stuff could be moved *out* from under "Kernel
hacking," such as "Sample kernel code."  right now, it's buried
partway down the hacking selection list, but i think it's useful
enough to deserve its own top-level entry at the bottom of the menu.
and if it's more prominent, that would encourage more people to write
code samples, as opposed to having that selection buried in the
Hacking/Debugging submenu where people might not even see it.  (and
being able to build sample kernel code really has nothing to do with
debugging, anyway.)

  anyway, just some random thoughts from an early saturday morning
at OLS 2008, waiting for someone to show up and turn on the
$^$(*&^#)*^_# wireless.

rday

p.s.  it should go without saying that it would be nice for a newer
"Kernel debugging" submenu to collect related topics into subsubmenus
to shorten what's there, like perhaps having a single selection to
debug all mutex/spinlock-related stuff, that sort of thing.  the
current layout *desperately* needs some subsubmenus for readability.
or at least a few comments to break things up.

--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================
--
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/