On 5/28/07, Ladislav Michl ladis@linux-mips.org wrote:
Principle described above has few serious drawbacks. Storage is no longer storage, but randomly mapped memory. As a u-boot programer you have to determine such memory map and as a u-boot user you have to remember it.
Exactly. Giving storage devices which aren't memory mapped a "virtual" address is a bad idea. And the database example is crap because it depends on hardware paging, which isn't being proposed here (how many architectures supported by u-boot can do 64-bit virtual address in hardware?)
That said, I do think Ulf has a point -- being able to compare a block of data in nand- or dataflash with something in memory (or other kinds of storage) is a pretty neat feature. But it should not be done by using "virtual" addresses (due to the problems described above), and it should be implemented in a generic way. Pouring #ifdefs all over cmd_mem.c is short-sighted and selfish.
I'm not sure if anyone's suggested this before, or whether it was well-received or not, but why don't we generalize the cmd_mem syntax a little? For example, let every memory address can be prefixed by an optional "storage specifier" and a ':' character. The default "storage specifier" is "mem", so that if it is omitted everything will work as before, but you can also do things like
cp.b df0:0x4200 0x85000000 cmp.l 0x24000000 nand1.1:0x123456789
and so on. Whatever comes after ':' is passed to the storage handler as a string, so if some storage types need 64-bit offsets, the handler can support it without disturbing anything else.
What do you think about something like that? The actual syntax probably needs some work to get right, and we need to take care to ensure backwards compatibility of course.
This does actually come quite close to Ulf's proposal, but instead of requiring the user to remember a "virtual address", we instead require him to enter a logical device and an offset, ie.. kind of a simple VFS without any actual files involved...
Haavard