[U-Boot] [PATCH 01/11] DM: add block device core

[Pavel Herrmann <morpheus.ibis@gmail.com>]

On Friday 21 of September 2012 20:00:10 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> [...]
> 
> > > > 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
> 
> So "blockctrl" == The controller driver? Viva abbrevs. Rename it to
> block_controller_driver .

thats far too long, dont you think? we only have 80 cols in code...

> > you can either implement your SD as a blockctrl and use that blockdev
> 
> SD as in ... SD card or SD host controller ? Use what blockdev ?

either we say we only have SD memory (and will never ever have other SDIO 
cards), implement SD controller with blockctrl API (and change it slightly, 
because SD is inherently flash and therefore has an erase operation)

on the other hand, we could have a separate API for SD controllers (richer 
than the blockctrl, to eventually suport non-memory SD cards), and then have a 
device that provides blockdev API on one end, and uses this SD API on the 
other (much like blockdev_ata in [5/11] does for blockctrl API).
this is the original idea; for this reason, blockdev API already has an erase 
operation, even though blockctrl does not support it.

> > , or
> > implement a separate blockdev for your SD card (this is the original
> > intention)
> 
> Ok, so the general abstration is to have a block_controller_driver
> (blockctrl in your parlance) for each and every driver in drivers/block

yes

> _and_ which provides only basic read/write block for the downstream drivers
> (block_device) attached to it

yes

> _and_ proxifies them for particular device type handlers?

not sure what you mean there. what device type handlers? is that 
SATA/SCSI/PATA? that should disappear, only reason i have it in code is 
because i am wrapping old APIs into the new one.

> Now block_device (blockdev) is either a whole disc, partition, or
> subpartition. It exports read/write block operations, but to complete them,
> it uses upcalls into it's parent, yes?

yes

> These upcalls stop at first block_controller_driver, correct?

in case of a hard disk, yes. in case of a USB flash, it uses USB calls to its 
parent (USB hub or whatever) to complete the task at hand

> The user only ever uses the read/write block operations of the block_device,
> yes?

yes

> > 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
> 
> They are not. But you should have looked at them since if you don't, that
> means you ignored fundamental part of the block interface.
> 
> But anyway, in case of SD card, the upcalls stop at block_controller_driver,
> which handles the block IO the specific SD controller way?

see above for the options. original idea is no, but it should be possible to 
implement it that way

> > > > > > > > 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?
> 
> I assume I do, confirm above.
> 
> > 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)
> 
> I see

Pavel Herrmann