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

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

On Saturday 22 of September 2012 15:33:10 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> > On Saturday 22 of September 2012 02:09:15 Marek Vasut wrote:
> > > Dear Pavel Herrmann,
> > > 
> > > [...]
> > > 
> > > > > > one or none - requests on USB flashes should not pass through
> > > > > > block_controller_driver.
> > > > > 
> > > > > Uh, what do they pass into then ?
> > > > 
> > > > their parent (an USB hub)
> > > 
> > > block_device instance (aka. partition/disk) directly connected to USB
> > > hub
> > > instance does not seem right.
> > 
> > why?
> 
> It doesn't make sense ... you need some kind of interim controller (like the
> chip between the USB and NAND in the thumbdrive.

yes, but you dont make drivers for every chip there is, instead the chips 
understand a common language, where you describe block operations by USB 
transfers, and that is exactly what saib block_device_usb_flash would do.

> > > > > > every child of block_controller should be a block_device (not
> > > > > > necessarily the other way around
> > > > > 
> > > > > I doubt it's even possible to be the other way around.
> > > > > 
> > > > > > ), so there is no way you pass more instances
> > > > > > block_controller on your way up.
> > > > > 
> > > > > Ok, let me explain again. Let's look at the USB case to make it more
> > > > > real-world- ish. Imagine you have a thumb drive with 2 partitions.
> > > > > Thus you have two instances of struct block_device [denote BDp] for
> > > > > the partitions and one more for the whole disc [denote BDd]. When
> > > > > you read from partition, you end up poking BDp, which pushes the
> > > > > request up into BDd. This in turn calls USB-flashdisc-
> > > > > block_controller_driver [call it UFc]. For flash disc to read data,
> > > > > it needs to do some USB transfers. These are provided by USB host
> > > > > controller [UHC]. Thus you need some glue between UHC and UFc ...
> > > > > this is what I'm talking about.
> > > > 
> > > > there should be no "UFc", your "BDd" driver should talk directly to
> > > > your "UHC"
> > > 
> > > So my generic partition implementation (BDd) would have to implement USB
> > > flashdisc stuff, correct? This makes no sense.
> > 
> > no. your generic USB flash would have to implement USB flashdisc stuff,
> > your generic partition implements block_device operations on top of other
> > block_device (aka diosk, memory card, USB flash)
> 
> Ok, so in your parlance, the block_device is either "partition/disc" or a
> "SD card controller driver" or "USB flashdisc driver" ? You are mixing
> these two things together?
> 
> > please read the letters you came up with right. (maybe after getting some
> > sleep by the looks of it)
> 
> I'd prefer to read some documented code.

im missing the point of this. you stateted that you have a partition "BDp" and 
a disk "BDd". i said your "BDd" will sit above USB API, and you stared ranting 
about partitions implementing USB stuff, which was totaly off.

> > the point you are not getting is that there should be more block_device
> > drivers than there is now - one for partitions, one for disk, one for USB
> > flash, one for SD and so on, each one using a different parent API
> 
> Ok, now I understand your intention. Split it -- make partitions separate,
> since this is flat out confusing!
> 
> Make partitions / whole disc a separate thing ...
> Make USB flash driver / SD card driver / etc. another thing ...
> 
> You can not mix these two together, it makes no sense.

well, disks, SD cards and USB flashes are one thing at the moment (see struct 
block_dev_desc). i am only adding partitions to the mix.

> > > > (a driver that has blockdev API on one end, USB on the other)
> > > 
> > > Ok, so how would this work, every partition implementation implements
> > > upcalls for all USB, SCSI, SATA, IDE, SD, ... and gazilion other types
> > > of
> > > drive it can sit on?
> > 
> > no, partition only implements call onto another block device
> > 
> > > > > Ok, I see the issue at hand. In case of a "regular drive", this
> > > > > implements the IO directly. In case of SD, this is a proxy object
> > > > > which interfaces with some SD-library and prepares the SD commands
> > > > > and then pushes that up into the controller to do the job? Same
> > > > > thing for USB flashes ?
> > > > 
> > > > not every block device will have a block controller as a parent (or
> > > > parent-of- parent in case of a partition). there would be a
> > > > blockdev-usb that has a USB hub as a parent, and a blockdev-mmc, that
> > > > has a mmc/sdio controller as a parent.
> > > 
> > > So you would have a specific partition implementation for SD, SATA, IDE,
> > > SCSI, USB ... ? This is flawed.
> > 
> > no, read above
> > 
> > > The partition should be a generic "thing" which knows nothing about
> > > where
> > > it's sitting at. So is the whole drive, same thing, it just has
> > > partitions hooked under it.
> > > 
> > > I'd expect a "block_controller" to be the proxy object under which the
> > > block_device representing the disc is connected. And this
> > > "block_controller" to be proxifying the requests to the respective
> > > drivers (be it SD, SATA, whatever).
> > 
> > your idea is wrong - you expect there will always be only one block_device
> > representig a "disk", and all the proxy would be done by the
> > block_controller above it. this is not true
> 
> Any amount of "block_device" can be connected under the "block_controller".
> Given that "block_device" is a partition/disc _only_ and "block_controller"
> is the interface driver ... which is probably not true, so you lost me
> again.

block controller muxes several disks onto one device (like a SATA controller 
does). you dont need this on USB drives and MMC cards, because you have a 
controller that can access multiple devices already (like the USB root hub)

if you took a look at the code you might see the point - the only thing you 
add by haveing a block_controller is a "port" parameter to every function, 
which you dont need in SD cards or USB flashes

> I stop here, this discussion leads nowhere. Can you please write proper
> documentation from which I can get an idea how this exactly works? Ideally
> with diagrams ... doc/driver-model/UDM-block.txt would be a good place.
> > Pavel Herrmann
> 
> Best regards,
> Marek Vasut