[lkml]   [2007]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjecttracking MAINTAINERS versus tracking SUBSYSTEMS

    this latest project of cramming the full definition of each kernel
    subsystem into the MAINTAINERS file has been bothering me, and i've
    finally figured out why. it's because the MAINTAINERS file is being
    asked to now be the source of reference information that just doesn't
    match its name. it's the "MAINTAINERS" file so it seems that all it
    should be keeping track of is the maintainer of each subsystem, and
    that's all.

    what people are clearly after is a way to match any part of the
    kernel source to a subsystem and, henceforth, to a maintainer, but
    there's nothing that says all of that has to be crammed into *that*

    why not add a new script to the kernel source tree that, given a
    file or directory name as an argument, returns its corresponding
    "subsystem" that can be cross-referenced against the MAINTAINERS file?
    something like:

    $ show_subsystem drivers/bluetooth/bpa10x.c

    there would seem to be a number of advantages to this approach:

    1) it reduces the MAINTAINERS file back to what it should be in the
    first place -- a simple reference list of each kernel subsystem, and
    who's responsible for it, so that constant reshuffling of files or
    directories in a particular subsystem doesn't require constant
    updating of the MAINTAINERS file.

    2) you could extend the show_subsystem() routine to, once it found the
    subsystem, quickly cross-reference the MAINTAINERS file and print out
    the corresponding maintainer. i believe the word "trivial" applies

    3) by making this a feature separate from the MAINTAINERS file, it can
    be mocked up and hacked separately and finally patched in when it's
    ready to go, rather than applying 5 bazillion patches to the poor

    4) finally, a feature like this could be used as a sanity check on the
    kernel subsystem structure. every once in a while, it could be
    invoked for every single file and directory in the tree, just to see
    if all of those appear to belong to at least one subsystem. if not,
    print a warning: "Whoa, file /fubar/snafu doesn't belong to a
    subsystem. Deal with it."

    the actual implementation would seem to be easy -- perhaps a simple
    text file that defines each subsystem and every file and directory
    that's part of it:

    FIREWIRE:drivers/firewire/,include/linux/firewire.h,... etc ...

    i mean, it doesn't get a whole lot simpler than that, and it would
    seem to be *way* easier to read.



    Robert P. J. Day
    Linux Consulting, Training and Annoying Kernel Pedantry
    Waterloo, Ontario, CANADA
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-18 19:47    [W:0.022 / U:0.136 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site