MTD Config.in items not escaped by bus availability
Brian J. Murrell
23025b7367b1a31e3ff7682b8a6ae18e at interlinx.bc.ca
Wed Oct 30 17:46:33 EST 2002
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
> - 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.
> This is a perfect interface for flash memory, might also be nice for
> cdrw, dvdram, etc. and sucks for most everything else.
> Yes, quite similar. The only use I see for this is development and
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.
> 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
> > > 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,
> "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. :-)
Brian J. Murrell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20021030/502cde85/attachment.bin
More information about the linux-mtd