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