[lkml]   [1996]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectProposal for cleaning up kernel driver parameters

    I've been thinking about how to best implement a "unified" way of
    setting driver parameters for kernel-resident and modularized
    drivers. This is what I think would be a nice, clean way of handling
    driver parameters...

    -- Treat the boot command line as a set of environment strings for the
    kernel. Drivers should be able to look things up by name, using an
    equivalent of getenv(). Take all the code for calling *_setup
    functions out of init/main.c: each driver should handle retrieving
    its own parameters.

    -- Implement the equivalent of the SYSV getsubopt() library function
    for the kernel. This function treats an argument as a series of
    comma-separated options, which may be keywords or keyword=value

    -- For backwards compatibility, we'll also have a kernel function that
    parses an argument into an array of ints, as the old *_setup()
    functions expect.

    To implement all this, we need to:

    -- Add the new parsing routines to the kernel.

    -- One by one, edit init/main.c to remove a *_setup() call, and modify
    the corresponding driver to use the new parsing routines.

    -- Later, modify the drivers to use keyword=value options, rather than
    the old int,int,int stuff.

    For modules, we could pass options in like:

    insmod i82365.o opts="irq_mask=0xefff,poll_status"

    and the module can then parse the option string using the same code it
    would use if linked into the kernel.


    -- Maintains nearly complete backwards compatibility. The only driver
    I know of that does its own fancy/incompatible boot line parsing is
    the IDE driver.

    -- More flexible, sane way of setting lots of parameters than the old
    "1[,2[,3[,4[,5[,6[,7]]]]]]" boot parameter scheme.

    -- Potentially safer than insmod's "modify any static symbol at will"

    -- Eliminates init/main.c dependencies on many config parameters.
    Which is part of my long-term goal of making driver selection just
    a link-time step :)


    -- More code required for stuff only done at initialization time. But
    I think the overhead should be pretty small: most drivers will just
    add a few keywords. I'd guess fewer than 100 bytes per driver for
    most drivers. And some drivers (like IDE) already have a lot of
    private code for doing essentially the same thing.

    What do people think? As another project, I've been thinking about
    how to provide a nicer interface for exposing "tuneable" kernel
    parameters so that they can be read/written on the fly. There are a
    few in /proc already, but I'd like to see lots more.

    -- Dave Hinds

     \ /
      Last update: 2005-03-22 13:38    [W:0.019 / U:4.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site