lkml.org 
[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Background to the argument about CML2 design philosophy
    Date

    Thankyou for the clarification.

    esr@thyrsus.com said:
    > I used case 3 to explore a touchy question about design philosophy,
    > which is really what caused all hell to break loose. The question is
    > this: holding down configuration complexity is a good thing, but
    > supporting all hardware configurations that are conceivably possible
    > is also a good thing. How should we trade these good things off
    > against one another?

    I think you already have the mechanism required to answer this - in NOVICE
    mode you disallow the strange choices, in EXPERT mode you allow them.

    Embedded boards are a special case in this respect - people add all manner
    of strange crap to the reference designs - believe me, I've seen the ways in
    which they can fuck it up and yet still they manage to amaze me sometimes.

    And because of the multitude of ways in which the monkeys who glue together
    these boards can fuck it up, often you really really want to ignore the
    on-board Ethernet, for example, and use the PCMCIA card you plugged in,
    because they actually managed to route the PCMCIA interrupt to an IRQ line,
    not a GPIO pin.


    esr@thyrsus.com said:
    > So the real question here is whether it is ever acceptable to say that
    > a possible configuration is just silly and ruleset will ignore it, in
    > order to hold down ruleset complexity and simplify the user
    > experience. The cost of deciding that the answer to that question is
    > "yes, sometimes" is that on rare occasions like this one you might
    > have to haul out a text editor to tweak something in your config.

    As I said earlier, there are two main cases which should be considered
    entirely separately. There are the cases which are insane, and which won't
    ever work, or probably even compile. Those should be hard-coded off in the
    ruleset and it should not be possible to enable them without hacking.

    For the cases where we just want to make life simpler for the users, the
    constraints should be dependent on the user mode. In NOVICE mode you hide
    them, in EXPERT mode you make them available.



    The current (CML1) solution has problems, and it only provides real support
    for a small range of people at the hacker end of the spectrum.

    Making CML2 useful for a far wider range of people is a laudable goal. But
    please take care to ensure that the set of people for whom CML2 is useful is
    a strict superset of those for whom CML1 was useful.

    In particular, please don't strive to make Aunt Tillie happy on the one
    occasion on which she configures her kernel at a cost of rendering CML2 less
    useful for those for whom kernel configuration is an every-day task. Once
    weighted appropriately, that tradeoff is particularly easy to decide upon.

    If you ever find yourself seriously suggesting that a developer would need
    to ditch CML2 and hack the config files directly in order to compile support
    for, for example, the DiskOnChip he just dropped into the DIL socket in his
    Ethernet card, then I would suggest that you have made a wrong choice
    somewhere down the road. Please backtrack and reconsider an earlier decision
    before you're eaten by a grue.

    We already have a distinction between config options which it's sensible to
    ask the user, and options for which you have to hack #defines in the source
    code. The options which I have put into drivers/mtd/Config.in are there
    because I _wanted_ the user to see them. The options which are hidden in
    the code are there because I made the opposite decision.

    There is a reasonably well-defined boundary for such things already, and
    it's found all over the kernel. Adding a new, higher boundary for Aunt
    Tillie is just fine - but please don't _move_ the existing one that most of
    us care about.

    --
    dwmw2


    -
    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-03-22 12:53    [W:2.518 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site