MTD Config.in items not escaped by bus availability
Jörn Engel
joern at wohnheim.fh-wedel.de
Thu Oct 31 11:53:22 EST 2002
On Wed, 30 October 2002 17:46:33 -0500, Brian J. Murrell wrote:
> Right. My example was a generalization around the whole MTD
> sub-system. If it were going to be finer grained to specific devices,
> the tests would specific to the bus(es) they can use.
Ok.
> But any device that requires access to physical hardware will break
> during a UML build if it is enabled during the configure. It should
> not even be selectable if it's required hardware is not selected,
> IMHO.
>
> > "need to be protected by"? Propably not. "don't make much sense
> > without"? Propable yes.
>
> And will break the building of a UML if selected. The idea is not to
> get a couple of hours into a kernel build and go "oooops, I forgot to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yeah, I once had a machine like that! ;-)
> disable ______ hardware driver" when the build breaks because of some
> hardware access not being available in the UML configuration.
Absolutely correct. A couple of test compiles convinced me.
> > This looks like a tradeoff between complexity in the Config.ins and in
> > .config or the make *config interface. If you want to keep the user
> > interface shorter and are willing to do the work, go ahead!
>
> It's fairly simple work in the Config.ins. I would do it but I don't
> really know what kinds of devices (i.e. buses) are required by the
> various MTD devices. I did do this work for PC apple/ethertalk cards
> and submitted it to Marcelo.
>
> I hoped I could bring you (rather, somebody, anybody with more
> knowlege about this than I) around. :-)
New sailor aboard, captain.
I'll try to create a sample patch soon. But it remains your duty to
make it production-ready and convince David.
Jörn
--
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
More information about the linux-mtd
mailing list