lkml.org 
[lkml]   [2005]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)
    On Tue, Sep 06, 2005 at 12:52:34PM +0200, Roman Zippel wrote:
    > I'm not really a big fan of such dummy symbols, those whole point is to
    > only enable dependencies, but are otherwise unsused.
    > The basic problem is similiar to selects, that one has to grep the whole
    > Kconfig to find out what modifies the dependencies of a symbol.
    >
    > If we really want to describe dependencies like this, I'd prefer to extend
    > the Kconfig syntax for this:
    >
    > config FOO
    > allow BAR
    >
    > config BAR
    > option hidden
    >
    > The hidden option would explicitly hide the symbol, unless otherwise
    > allowed.

    I doubt that we really need that - there are, fortunately, very few drivers
    that need either form.

    Note that what happens here is very unusual:
    * driver is for hardware shared by quite a few (sub)architectures
    * it requires different (and irregular) glue for all of them
    * it doesn't exist for more and more new architectures and never
    existed for many old ones
    * the same is true for subarchitectures of arm/mips/ppc - hell, even
    for m68k, except that there we don't get new ones.
    * it's not tied to any bus

    Keeping a list of targets that must be excluded is obviously losing variant -
    there will be more and more of those. Flipping to "it's allowed on <list>"
    generates a big mess; yeah, you get a long expression that tells you where
    is that sucker defined. And it turns into a convoluted way to say "many
    platforms have that, many do not, it's really up to platform, no general
    rules here". Which is exactly what
    depends on ARCH_MAY_HAVE_PC_FDC
    is saying in far more readable way.

    We could go for your "allow" form, but what else would need it? USB gadget
    stuff with its "must have at most one low-level driver, high-level drivers
    should be allowed only if a low-level one is present"? RTC mess is better
    solved in other ways, PARPORT_PC is mostly solved by now, what's left?
    VGA_CONSOLE? I really don't see enough uses for such construct...
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-09-06 15:52    [W:0.022 / U:31.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site