On Friday 21 of September 2012 17:55:10 Marek Vasut wrote:
Dear Pavel Herrmann,
On Friday 21 of September 2012 17:34:27 Marek Vasut wrote:
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?
you should have a blockdev driver for USB flash and SD, but not blockctrl
I'm lost again. Do I also need a blockdev driver for SATA controller now that I need a blockdev driver for SD card controller ?
you need a blockdev for a blockctrl (see [5/11]), and you need a blockctrl driver for your SATA controller
you can either implement your SD as a blockctrl and use that blockdev, or implement a separate blockdev for your SD card (this is the original intention)
I have not looked at current SD API, but i do recall seeing some non-memory SDIO cards (wifi for example, not sure u-boot supports this though), so i dont think SD should be implemented as a blockctrl
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?
yes, you can do raw reads, but in most cases you are using a filesystem.
Not true, see how env is stored to these media.
i put filesystem there to differentiate from nand devices (which have a special flash- based filesystems in most cases).
Not true, raw IO on flash media is often used too.
- 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.
no, blockdev shoud be the last common part, for SD/USB, you should have a different blockdev driver, that uses USB/SD API for the actual works
blockctrl is just an unified look at whatever now resides in drivers/block
Answer my question, you are contradicting yourself in your answer. So again, does "blockctrl" do the muxing between the downstream drivers (SD blockdev, USB blockdev, SATA blockdev, IDE blockdev ... ) ?
again, no
blockctrl is a common API primarily for SATA/PATA/SCSI controllers, blockdev is an abstraction of any block device, therefore you should have a AHCI blockctrl, piix blockctrl, bfin blockctrl, sil3114 blockctrl (add anything from drivers/block) but a USB blockdev and SD blockdev.
see the difference?
the idea is that there would be no difference when working with SATA/PATA/SCSI (as the commands are almost the same currently), but working with USB drives and SD cards would be a little different (that is from their own separate commands, but not through the blockdev layer)
Pavel Herrmann