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

[Marek Vasut]

Dear Pavel Herrmann,

> 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...

So what? You can abbrev. the variable name, so it won't get in the way. As you 
can see, I was confused by the name, do you expect others not to be?

> > > 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.

I mean the particular block_controller_driver instance routes the "read/write 
block" request from downstream block_device through SATA/SD/SCSI/whatever 
"library" or "layer" back into itself. But the later "itself" is the 
implementation of the "library" or "layer" API. Once the library call returns, 
the "read/write block" operation is complete and the result can be passed back 
to the downstream "block_device". Yes?

> > 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

Let me reformulate -- there is only single block_controller_driver instance the 
request crosses on it's way up the driver tree. Yes?

[...]

Best regards,
Marek Vasut