dwmw2 at infradead.org
Sun Mar 12 12:26:38 EST 2000
alex at cendio.se said:
> I'm aware of the normal conventions for read (2), but is this good in
> the kernelspace api? I mean, the only reason for a flash to not read
> all data is if the flash is paged, and you don't want to bother
> changing page in the read function. On the other hand, all places in
> the kernel that read data from the flash except the char device read
> op (ie. the block device, mtd, flash filesystems etc) needs to loop on
> each read.
In practice, this hasn't mattered because the devices allow you to read up to
a block at a time, and the block device and flash filesystems usually want to
read <= 1 block. The only place that has to retry is the mtd chardevice, which
means the retry is in userspace.
However, that behaviour isn't guaranteed, so strictly speaking, perhaps we
ought to change it. How about simply declaring that the read() functions MUST
read up to the end of the block on which they start, and may not return an
incomplete read unless requested to do a multi-block read.
That would make it safe for all current the kernel-space users, wouldn't it?
> But if the device is fully memory mapped the current point()/
> unpoint() api is a bit overweight. A pointer and size would be enough.
Fine. Then it can go too. Just as soon as I've stopped ftl.c from using it :)
To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
More information about the linux-mtd