lkml.org 
[lkml]   [2008]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support
    Adrian Bunk wrote:
    > On Sun, Jan 06, 2008 at 01:18:48PM +0100, Stefan Richter wrote:
    >> I'm afraid this can't be put into practice. (User says which hardware
    >> and protocols he needs to be supported, scripts magically assemble a
    >> suitable configuration.)
    >
    > Distribution installers and live CDs like Knoppix even manage to
    > magically assemble a suitable configuration (e.g. autodetecting which
    > modules they should load) without asking the user any questions.

    Module autoloading is quite different.

    > The information the user has to give when configuring his kernel is
    > whether he wants to connects USB disks - whether or not the
    > implementation of the kernel driver uses the in-kernel SCSI layer we can
    > easily handle automatically without bothering the user.
    >
    >> I think
    >> - sensibly modularize our software,
    >> - tell the user which software components there are,
    >> - what they are for,
    >> - how they depend on each other,
    >> - make it easy enough for the user to navigate in the dependency
    >> graph,
    >> - provide fundamental safeguards and checks for a proper software
    >> configuration
    >> is the best we can do.
    >
    > It sounds strange that what you call the "the best we can do" would be
    > much worse than what we are currently doing...
    >
    > The current status quo is that a user e.g. only has to know that his
    > ethernet controller is a "Broadcom 440x/47xx", the fact that a Sonics
    > Silicon Backplane bus is used on the card is handled automatically by
    > kconfig.

    if NET_ETHERNET
    ...
    config B44
    tristate "Broadcom 440x/47xx ethernet support"
    depends on SSB_POSSIBLE
    select SSB
    select MII
    ...
    endif # NET_ETHERNET

    There is a B44 option. The prompt string (in other cases the help text)
    tells what it is for. Furthermore, four dependencies are encoded; one
    in the direct form, one by if/endif, two in reverse form. There are no
    further hints how to satisfy SSB_POSSIBLE, NET_ETHERNET, SSB, MII. The
    kconfig system is told to enable SSB and MII no matter what, as long as
    SSB_POSSIBLE, NET_ETHERNET, and B44 are != n.

    This /is/ what we are currently doing, not "worse than what we are
    currently doing". We
    - sensibly modularize our software,
    - tell the user which software components there are,
    - what they are for,
    - how they depend on each other,
    - make it easy enough for the user to navigate in the dependency
    graph,
    - provide fundamental safeguards and checks for a proper software
    configuration. (Well, we actually walk on thin ice whenever we
    use the 'select' keyword.)

    (Now, after the b44.ko has been built and installed, the object file
    should contain aliases which let modern userland automatically load this
    kernel object if respective hardware has been detected and the module
    wasn't blacklisted. So, run-time configuration is more comfortable than
    build-time configuration, except that help texts aren't as easily
    accessible at run-time as they are at build-time.)
    --
    Stefan Richter
    -=====-==--- ---= --==-
    http://arcgraph.de/sr/


    \
     
     \ /
      Last update: 2008-01-06 14:17    [W:0.030 / U:0.516 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site