On Wed, Aug 07, 2002 at 01:16:48PM +0100, Alan Cox wrote:
> On Wed, 2002-08-07 at 11:41, Andi Kleen wrote:
> > I don't see why it is unmaintainable. What is so bad with these ifs?
> > 64bit cleanness is just another dependency, nothing magic and fundamentally
> > hard.
>
> Lets take I2O block the if rule would
>
> if [ $CONFIG_X86 = "y" -a $CONFIG_X86_64 != "y" ]
> dep_bool ...
dep_bool .... $CONFIG_X86_32
Would that be acceptable for you? (ok that would not cover ppc32 for
example, but they may have other issues with the driver)
> The actual rule being if 32bit little endian || 64bit little endian with
> kernel memory objects always below 4Gb and having PCI bus
I don't see it as a that big problem. It just needs a few more negated
generic symbols defined (e.g. CONFIG_32BIT CONFIG_4GB_ONLY
CONFIG_LITTLE_ENDIAN), then it could be easily expressed with dep_... even
in the traditional configuration language. I also don't think it would
be particularly unmaintainable to have these things in Config.
>
>
> Thats just one non too complicated driver. CML1 can't handle this
> scalably, maybe CML2 could have.
>
> Secondly you actually want people to discover stuff doesn't work so you
> can persuade them to go and fix it. Stick up a 'Good/Probably
They will discover it when they don't find a driver for an device and
can then find the disabled configuration and look into fixing it
(for someone able to fix the driver checking the configuration should
be trivial)
In my opinion it is just not acceptable when the enable the driver by
mistake or load the wrong module and it crashes.
> Ok/Bad/Hopeless' driver listing on x86_64.org, then once Hammer becomes
> in general use post it to the janitor list now and then
That will be likely done anyways, but it is not enough.
-Andi
-
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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:35 EST