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

["Brian J. Murrell" <23025b7367b1a31e3ff7682b8a6ae18e@interlinx.bc.ca>]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

On Wed, Oct 30, 2002 at 10:43:41PM +0100, Jörn Engel wrote:
> 
> In simple terms, mtd is an interface to read, write and erase memory
> devices:
> - Read any part of the device.
> - Write any part of the device, writing only flips 1s to 0s.
> - Erase predefined blocks atomically, erasing flips all 0s in the
>   block to 1s.

OK.

> This is a perfect interface for flash memory, might also be nice for
> cdrw, dvdram, etc. and sucks for most everything else.

I see.

> Yes, quite similar. The only use I see for this is development and
> testing,

Which coincides with the use of UML nicely.

> but that is not the worst use. A notebook with uml is
> sufficient to do a lot of stuff without real hardware.

Right.

> Kinda. You need some sort of memory to create an mtd device from. But
> this memory does not have to be real hardware, just as you can create
> filesystems on raid devices, network block devices, loopback files,...

OK, so the general MTD subsystem is applicable without hardware, parts
are not though.

> Maybe. The stuff in drivers/mtd/chips and /nand looks like a good
> candidate.

Right.

> > > You can say, it already is. But 
> > > 
> > > [ "$CONFIG_MEMORY_BUS" = "y" -o
> > >   "$CONFIG_HAS_MEMORY" = "y" -o
> > >   "$CONFIG_HAS_BLOCK_DEVICES" = "y" ]
> 
> -o is the key. ;-)
> Any system sans uml has a memory bus and uml has block devices.

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.

> So the
> test evaluates to true in either case. Ignoring it completely keeps
> Config.in shorter and simpler, which is a Good Thing(tm).

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
disable ______ hardware driver" when the build breaks because of some
hardware access not being available in the UML configuration.

> 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.

> Actually, the longer I think about it, the more sense it makes. Might
> really be a good idea.

I hoped I could bring you (rather, somebody, anybody with more
knowlege about this than I) around.  :-)

b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]