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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/