lkml.org 
[lkml]   [2001]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Re: 2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
    Hi Russell.

    >> Q> dep_arch_tristate ' AM79C961A support' CONFIG_ARM_AM79C961A \
    >> Q> ACORN $CONFIG_NET_ETHERNET

    > Before we go and create a patch for Linus to apply...

    Who's sent a patch to Linus? I haven't, and don't intend to do so.

    > ...please note that the above is totally bogus and is in fact
    > 100% wrong.

    Please explain? I don't see the problem with the proposed syntax, and
    presume you have noticed that it's a new statement type, not a
    modification to an existing one?

    > Don't create a patch yourself. Let me know how you propose to do
    > it, and I will create the patch using the correct symbols.

    OK, here's the proposal:

    1. Define new config statements that take as their parameters the
    following:

    1. The prompt text.

    2. The name of the config variable to set.

    3. The NAME of the config variable that defines the
    required architecture.

    4. The VALUES of all other config variables this variable
    depends on.

    2. Define the new `dep_arch_bool` statement to be the same as
    `dep_bool` if passed items 1, 2 and 4 when the config var
    named in item 3 has the value "y". When the config var named
    has any other value, it becomes `define_bool "$2" "n" instead.

    3. Define the new `dep_arch_tristate` similarly.

    > Also note that the majority of the machine-dependent symbols for
    > StrongARM platforms (of which there are around 43) start
    > CONFIG_SA1100_*, not CONFIG_ARCH_*. Unfortunately, its far too
    > late to get around this special case (I'm not too happy that we
    > have this special case either, so don't whinge at me please).

    First, why is it "far too late" as you put it? It won't be the first
    time config vars have been renamed, and it's unlikely to be the last
    either...

    Secondly, that isn't a problem to this proposal. The reason for taking
    the CONFIG_ARCH_ out of the syntax is to emphasise that it's the name
    and not the value that goes in there, thus reducing the likelihood of
    problems creeping in in the first place.

    Best wishes from Riley.

    -
    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:55    [W:0.027 / U:2.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site