Re: MTD Config.in items not escaped by bus availability

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

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