Dear Pavel Herrmann,
[...]
blockctrl = AHCI, PIIX... whichever chip you have between SATA and PCI (or generally disk-bus and board-bus)
So this is for sata ? Or will it also by used for SD/USB flash discs?
no, blockctrl will be used for SATA, PATA, SCSI, and anything of the sort (device with several ports, block devices on said ports, ability to send read/write/query commands to devices on ports - definitely not USB, possibly also SD, but you probably want more operations from SD)
Why not USB flash ? Why not SD, what other stuff do you need for that? Is the API not misdesigned then?
blockdev = disk, partition, SD card
Uh, let's say I understand (even if I don't see the correlation between partition and SD card)
they are an ordered bunch of blocks with a "conventional" filesystem on them
You might want to do RAW reads, so why do you put filesystem into this context?
- something that does basic checks
(range, possibility of operation) and submits operations to correct parent (blockctrl, MMC controller, whatnot).
Ascii art might help here greatly (how these pieces fall together). I think I do understand it though.
current code user -> FS -> offset calculation from partition info -> drivers/disk
new code user -> FS -> blockdev -> blockctrl (or USB or SD controller)
So your "blockctrl" should do the USB/SD/whatever muxing.
partition blockdev does all the offset calculation and range check that FSs do now, and then submits the operation to the parent blockdev, which in turn submits it to blockctrl (or an SD controller in case of a SD card, or USB controller in case of a USB flash)
Make sure you document this in the next series.
Pavel Herrmann
Best regards, Marek Vasut