Add DM blockdev subsystem

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---
 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121
++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164
insertions(+)
 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

Dear Pavel Herrmann,

Quoted 11 lines

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121

Quoted 5 lines

++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164 insertions(+)

 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

Why not use drivers/block/ ?

Quoted 16 lines

Dear Pavel Herrmann,

Quoted 14 lines

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121

++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164 insertions(+)

Quoted 4 lines

Quoted 2 lines

 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

Why not use drivers/block/ ?

Because the drivers in drivers/block have a different purpose than blockdev.

I would expect this question for blockctrl, there i just try to avoid confusion about being completely compatible

Pavel Herrmann

Dear Pavel Herrmann,

Quoted 20 lines · On Thursday 20 of September 2012 21:58:17 Marek Vasut wrote:

Quoted 19 lines

Dear Pavel Herrmann,

Quoted 16 lines

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121

++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164 insertions(+)

 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

Quoted 4 lines

Quoted 1 line

Why not use drivers/block/ ?

Because the drivers in drivers/block have a different purpose than blockdev.

Different, ok. Can you elaborate how is it different?

Quoted 27 lines

Dear Pavel Herrmann,

Quoted 24 lines · On Thursday 20 of September 2012 21:58:17 Marek Vasut wrote:

Quoted 13 lines

Dear Pavel Herrmann,

Quoted 11 lines

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121

Quoted 7 lines

Quoted 5 lines

++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164 insertions(+)

 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

Why not use drivers/block/ ?

Because the drivers in drivers/block have a different purpose than blockdev.

Quoted 1 line

Different, ok. Can you elaborate how is it different?

blockctrl is equivalent in purpose to drivers/block, just a new approach

blockctrl = AHCI, PIIX... whichever chip you have between SATA and PCI (or generally disk-bus and board-bus)

blockdev = disk, partition, SD card

- something that does basic checks
(range, possibility of operation) and submits operations to correct parent (blockctrl, MMC controller, whatnot).

Also this gets rid of all partition-related code in filesystems, because the access to a partition and to the whole disk is the same, no need to manually compute offsets every time (and you can support discontinuous partitions, if you chose to do so)

Pavel Herrmann

Dear Pavel Herrmann,

Quoted 29 lines · On Friday 21 of September 2012 14:39:14 Marek Vasut wrote:

Quoted 28 lines

Dear Pavel Herrmann,

Quoted 25 lines · On Thursday 20 of September 2012 21:58:17 Marek Vasut wrote:

Quoted 13 lines

Dear Pavel Herrmann,

Quoted 11 lines

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121

Quoted 8 lines

Quoted 6 lines

++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164
insertions(+)

 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

Why not use drivers/block/ ?

Because the drivers in drivers/block have a different purpose than blockdev.

Quoted 6 lines

Quoted 1 line

Different, ok. Can you elaborate how is it different?

blockctrl is equivalent in purpose to drivers/block, just a new approach

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?

Quoted 1 line

blockdev = disk, partition, SD card

Uh, let's say I understand (even if I don't see the correlation between partition and SD card)

Quoted 3 lines

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

Quoted 4 lines

Quoted 2 lines

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)

Quoted 4 lines

Quoted 1 line

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

Quoted 4 lines

Quoted 3 lines

- something that does basic checks
(range, possibility of operation) and submits operations to correct parent (blockctrl, MMC controller, whatnot).

Quoted 2 lines

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)

partition blockdev does all the offset calculation and range check that FSs do now, and then submits the operation to the parent blockdev, which in turn submits it to blockctrl (or an SD controller in case of a SD card, or USB controller in case of a USB flash)

Pavel Herrmann

Dear Pavel Herrmann,

[...]

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 4 lines

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?

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

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?

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 5 lines

partition blockdev does all the offset calculation and range check that FSs
do now, and then submits the operation to the parent blockdev, which in turn submits it to blockctrl (or an SD controller in case of a SD card, or USB controller in case of a USB flash)

Make sure you document this in the next series.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Quoted 14 lines

Dear Pavel Herrmann,

[...]

Quoted 9 lines

Quoted 4 lines

Quoted 2 lines

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)

Quoted 2 lines

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

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

blockdev = disk, partition, SD card

Uh, let's say I understand (even if I don't see the correlation between partition and SD card)

Quoted 5 lines

Quoted 2 lines

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.

i
put filesystem there to differentiate from nand devices (which have a special flash- based filesystems in most cases).

Quoted 13 lines

Quoted 12 lines

Quoted 6 lines

Quoted 3 lines

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

Quoted 1 line

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

Quoted 6 lines

Quoted 5 lines

partition blockdev does all the offset calculation and range check that FSs
do now, and then submits the operation to the parent blockdev, which in turn submits it to blockctrl (or an SD controller in case of a SD card, or USB controller in case of a USB flash)

Quoted 6 lines

Make sure you document this in the next series.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Dear Pavel Herrmann,

Quoted 16 lines · On Friday 21 of September 2012 17:34:27 Marek Vasut wrote:

Quoted 15 lines

Dear Pavel Herrmann,

[...]

Quoted 10 lines

Quoted 5 lines

Quoted 2 lines

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)

Quoted 5 lines

Quoted 3 lines

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 ?

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

blockdev = disk, partition, SD card

Uh, let's say I understand (even if I don't see the correlation between partition and SD card)

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 17 lines

Quoted 16 lines

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

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

Quoted 5 lines

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.

Quoted 4 lines

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

Quoted 5 lines

Quoted 2 lines

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

Quoted 44 lines

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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

Quoted 5 lines

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 21 lines

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

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

Quoted 8 lines

Quoted 6 lines

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

Quoted 6 lines

Quoted 2 lines

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

Dear Pavel Herrmann,

[...]

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

you should have a blockdev driver for USB flash and SD, but not blockctrl

Quoted 5 lines

Quoted 2 lines

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 .

Quoted 1 line

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 ?

Quoted 3 lines

, 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

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

_and_ proxifies them for particular device type handlers?

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?

These upcalls stop at first block_controller_driver, correct?

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

Quoted 4 lines

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?

Quoted 52 lines

Quoted 45 lines

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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

Quoted 5 lines

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 22 lines

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

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

Quoted 8 lines

Quoted 6 lines

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

Quoted 6 lines

Quoted 2 lines

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

Quoted 8 lines

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.

Quoted 4 lines

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

Quoted 10 lines

Dear Pavel Herrmann,

[...]

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

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 ?

Quoted 5 lines

Quoted 2 lines

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

Quoted 3 lines

Quoted 1 line

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.

Quoted 6 lines

Quoted 3 lines

, 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

Quoted 2 lines

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

yes

Quoted 1 line

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

Quoted 3 lines

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

Quoted 1 line

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

Dear Pavel Herrmann,

Quoted 11 lines · On Friday 21 of September 2012 20:00:10 Marek Vasut wrote:

Quoted 10 lines

Dear Pavel Herrmann,

[...]

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

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 ?

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

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?

Quoted 28 lines

Quoted 3 lines

Quoted 1 line

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.

Quoted 6 lines

Quoted 3 lines

, 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

Quoted 2 lines

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

Quoted 7 lines

yes

Quoted 1 line

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 4 lines

Quoted 1 line

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?

Quoted 7 lines

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?

in that case no, the block controller should directly take care of the call, without it being translated into some form it likes better for its particular interface.

the translation is udes as a mechanism to support old code, but eventually there should be none, and the drivers should take a request from block_device and take care of it (probably by using memory-mapped access, or however you communicate with that chip).

there might be a shared library for old IDE drivers though, as they are more like a shared code with driver (and board)-specific hooks.

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

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

Quoted 1 line

These upcalls stop at first block_controller_driver, correct?

Quoted 5 lines

Quoted 2 lines

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?

one or none - requests on USB flashes should not pass through block_controller_driver.

every child of block_controller should be a block_device (not necessarily the other way around

), so there is no way you pass more instances
block_controller on your way up.

Dear Pavel Herrmann,

[...]

Quoted 8 lines

Quoted 7 lines

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?

Quoted 3 lines

in that case no, the block controller should directly take care of the call, without it being translated into some form it likes better for its particular interface.

This is entirely wrong. This would mean for example for SD drivers, to implement whole SD stack.

Quoted 20 lines

the translation is udes as a mechanism to support old code, but eventually there should be none, and the drivers should take a request from block_device and take care of it (probably by using memory-mapped access, or however you communicate with that chip).

there might be a shared library for old IDE drivers though, as they are more like a shared code with driver (and board)-specific hooks.

Quoted 12 lines

Quoted 11 lines

Quoted 4 lines

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

Quoted 1 line

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

Quoted 5 lines

Quoted 2 lines

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

one or none - requests on USB flashes should not pass through block_controller_driver.

Uh, what do they pass into then ?

Quoted 2 lines

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.

Quoted 2 lines

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

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 ?

Quoted 4 lines

Quoted 2 lines

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)

Quoted 8 lines

Quoted 2 lines

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.

Quoted 2 lines

), so there is no way you pass more instances
block_controller on your way up.

Quoted 9 lines

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"

(a driver that has blockdev API on one end, USB on the other)

Quoted 5 lines

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 basically what you mean, without the block_controller in the middle - please note that the block_device API is actually richer than the block_controller API (has erase) for exactly this reason.

Pavel Herrmann

Dear Pavel Herrmann,

[...]

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

one or none - requests on USB flashes should not pass through block_controller_driver.

Quoted 3 lines

Quoted 1 line

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.

Quoted 18 lines

Quoted 17 lines

Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 2 lines

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.

Quoted 1 line

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

Quoted 6 lines

Quoted 5 lines

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 ?

Quoted 4 lines

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.

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

Quoted 7 lines

Dear Pavel Herrmann,

[...]

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

one or none - requests on USB flashes should not pass through block_controller_driver.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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?

Quoted 22 lines

Quoted 21 lines

Quoted 8 lines

Quoted 2 lines

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.

Quoted 2 lines

), so there is no way you pass more instances
block_controller on your way up.

Quoted 10 lines

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"

Quoted 2 lines

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)

please read the letters you came up with right. (maybe after getting some sleep by the looks of it)

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

Quoted 5 lines

Quoted 1 line

(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

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

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 ?

Quoted 7 lines

Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 4 lines

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

Pavel Herrmann

Dear Pavel Herrmann,

Quoted 12 lines · On Saturday 22 of September 2012 02:09:15 Marek Vasut wrote:

Quoted 11 lines

Dear Pavel Herrmann,

[...]

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

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)

Quoted 5 lines

Quoted 3 lines

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.

Quoted 22 lines

Quoted 22 lines

Quoted 21 lines

Quoted 8 lines

Quoted 2 lines

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.

Quoted 2 lines

), so there is no way you pass more instances
block_controller on your way up.

Quoted 10 lines

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"

Quoted 6 lines

Quoted 2 lines

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?

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 35 lines

Quoted 6 lines

Quoted 1 line

(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

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

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 ?

Quoted 7 lines

Quoted 4 lines

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

Quoted 9 lines

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

Quoted 3 lines

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.

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.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Quoted 14 lines · On Saturday 22 of September 2012 15:33:10 Marek Vasut wrote:

Dear Pavel Herrmann,

Quoted 12 lines · On Saturday 22 of September 2012 02:09:15 Marek Vasut wrote:

Quoted 11 lines

Dear Pavel Herrmann,

[...]

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

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)

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 38 lines

Quoted 25 lines

Quoted 25 lines

Quoted 24 lines

Quoted 8 lines

Quoted 2 lines

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.

Quoted 2 lines

), so there is no way you pass more instances
block_controller on your way up.

Quoted 13 lines

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"

Quoted 8 lines

Quoted 3 lines

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?

Quoted 5 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 4 lines

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

Quoted 7 lines

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.

Quoted 42 lines

Quoted 37 lines

Quoted 6 lines

Quoted 1 line

(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

Quoted 12 lines

Quoted 11 lines

Quoted 5 lines

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.

Quoted 3 lines

So you would have a specific partition implementation for SD, SATA, IDE,
SCSI, USB ... ? This is flawed.

no, read above

Quoted 9 lines

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

Quoted 4 lines

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

Quoted 6 lines

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

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---
 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 164 insertions(+)
 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

On Fri, Sep 21, 2012 at 1:07 AM, Pavel Herrmann <[email protected]>

Quoted 14 lines

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121
 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164
 insertions(+)
 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

<snip>

include/dm/blockdev.h line 74

Quoted 7 lines

include/dm/blockdev.h new file +7 -0

+struct blockdev_ops {
+       lbaint_t        (*read)(struct instance *inst, lbaint_t start,
+                               lbaint_t blkcnt, void *buffer);
+       lbaint_t        (*write)(struct instance *inst, lbaint_t start,
+                               lbaint_t blkcnt, void *buffer);
+       lbaint_t        (*erase)(struct instance *inst, lbaint_t start,
+                               lbaint_t blkcnt);

lbaint_t is little "cryptic". Any better name suggestions?

Hi

Quoted 1 line · On Friday 21 of September 2012 02:19:00 Vikram Narayanan wrote:

On Fri, Sep 21, 2012 at 1:07 AM, Pavel Herrmann <[email protected]>

Quoted 25 lines · wrote:

Quoted 14 lines

This core will register all block devices (disk, cards, partitons) and provide unfied access to them, instead of current method with device + partition offset

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                  |   1 +
 drivers/blockdev/Makefile |  42 ++++++++++++++++
 include/dm/blockdev.h     | 121
 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 164
 insertions(+)
 create mode 100644 drivers/blockdev/Makefile
 create mode 100644 include/dm/blockdev.h

<snip>

Quoted 7 lines

include/dm/blockdev.h new file +7 -0

+struct blockdev_ops {
+       lbaint_t        (*read)(struct instance *inst, lbaint_t start,
+                               lbaint_t blkcnt, void *buffer);
+       lbaint_t        (*write)(struct instance *inst, lbaint_t start,
+                               lbaint_t blkcnt, void *buffer);
+       lbaint_t        (*erase)(struct instance *inst, lbaint_t start,
+                               lbaint_t blkcnt);

Quoted 1 line

lbaint_t is little "cryptic". Any better name suggestions?

lbaint_t is an unsigned 32bit or 64bit number, depending on state of CONFIG_LBA48.

It was chosen because some parts of current block code use it as well, but we can pretty much replace it with size_t (and assume CONFIG_LBA48 is always on)

Pavel Herrmann

drivers/blockdev/core.c new file +34 -0

+struct blockdev_id {
+	struct {
+		unsigned type:BLOCKDEV_IFTYPE_BITS;
+		unsigned number:(16-BLOCKDEV_IFTYPE_BITS);
+	} disk;
+	unsigned partition:16;
+};
+
+static struct blockdev_id invalid_id = {{0xf, 0xfff}, 0xffff};
+static struct blockdev_id empty_id = {{0x0, 0x0}, 0x0};
+
+static inline int id_cmp(const struct blockdev_id *left,
+	const struct blockdev_id *right)
+{
+	return memcmp(left, right, sizeof(struct blockdev_id));
+}
+
+struct blockdev_core_entry {
+	struct list_head	list;
+	struct instance		*instance;
+	struct blockdev_ops	*ops;
+	struct blockdev_id	name;
+};
+
+struct blockdev_core_private {
+	/* Put cache here */
+};
+
+struct bdid_instance_pair {
+	struct blockdev_id	id;
+	struct instance		*inst;
+};
+
+static struct blockdev_core_entry *get_entry_by_instance(struct instance

*i) +{

drivers/blockdev/core.c new file +96 -0

+	struct blockdev_core_entry *tmp;
+	struct core_instance *core = get_core_instance(CORE_BLOCKDEV);
+
+	if (!core)
+		return NULL;
+
+	list_for_each_entry(tmp, &core->succ, list)
+		if (tmp->instance == i)
+			return tmp;
+
+	return NULL;
+}
+
+static struct blockdev_core_entry *get_entry_by_id(struct blockdev_id id)
+{
+	struct blockdev_core_entry *tmp;
+	struct core_instance *core = get_core_instance(CORE_BLOCKDEV);
+
+	if (!core)
+		return NULL;
+
+	list_for_each_entry(tmp, &core->succ, list)
+		if (!id_cmp(&tmp->name, &id))
+			return tmp;
+
+	return NULL;
+}
+
+static inline int try_match_name(enum blockdev_iftype type,
+	struct blockdev_id *id, char **name)
+{
+	int len = strlen(blockdev_name[type]);
+
+	if (!strncmp(*name, blockdev_name[type], len)) {
+		id->disk.type = type;
+		*name += len;
+		return 0;
+	}
+	return 1;
+}
+
+static struct blockdev_id get_id_from_name(char *name)
+{
+	struct blockdev_id disk_id = empty_id;
+
+	if (!try_match_name(BLOCKDEV_IFTYPE_UNKNOWN, &disk_id, &name))
+		goto get_number;
+	if (!try_match_name(BLOCKDEV_IFTYPE_ATA, &disk_id, &name))
+		goto get_number;
+	if (!try_match_name(BLOCKDEV_IFTYPE_SD, &disk_id, &name))
+		goto get_number;
+	if (!try_match_name(BLOCKDEV_IFTYPE_USB, &disk_id, &name))
+		goto get_number;
+
+	return invalid_id;
+
+get_number:
+	/* get disk number from name */
+	if ((*name < '0') || (*name > '9'))
+		return invalid_id;
+
+	disk_id.disk.number *= 10;
+	disk_id.disk.number += (*name-'0');
+	name++;
+
+	switch (*name) {
+	case 0:
+		return disk_id;
+	case BLOCKDEV_PARTITION_SEPARATOR:
+		name += 1;
+		goto get_part;
+	default:
+		goto get_number;
+	}
+	return invalid_id;
+
+get_part:
+	/* get partition number fron name */
+	if ((*name < '0') || (*name > '9'))
+		return invalid_id;
+
+	disk_id.partition *= 10;
+	disk_id.partition += (*name-'0');
+	name++;
+
+	switch (*name) {
+	case 0:
+		return disk_id;
+	default:
+		goto get_part;
+	}
+
+	return invalid_id;
+}
+
+static int get_free_index(struct core_instance *core, enum blockdev_iftype

type) +{

drivers/blockdev/core.c new file +12 -0

+	int retval = 0;
+	struct blockdev_core_entry *entry;
+
+	list_for_each_entry(entry, &core->succ, list) {
+		if ((entry->name.disk.type == type) &&
+			(entry->name.disk.number >= retval))
+				retval = entry->name.disk.number + 1;
+	}
+
+	return retval;
+}
+

drivers/blockdev/core.c new file +44 -0

+	else {
+		/* for a partition, we find its parent and use its name */
+		if (hint->iftype == BLOCKDEV_IFTYPE_PARTITION) {
+			entry = get_entry_by_instance(dev->bus);
+			retval.disk = entry->name.disk;
+			retval.partition = hint->part_number;
+			return retval;
+		/* if we have a valid hint for a disk, get a free index */
+		} else {
+			retval.disk.type = hint->iftype;
+			retval.disk.number = get_free_index(core, hint->iftype);
+			retval.partition = 0;
+		}
+	}
+
+	return retval;
+}
+
+/* Core API functions */
+static int get_count(struct core_instance *core)
+{
+	int cnt = 0;
+	struct blockdev_core_entry *entry = NULL;
+
+	list_for_each_entry(entry, &core->succ, list)
+		cnt++;
+
+	return cnt;
+}
+
+static struct instance *get_child(struct core_instance *core, int index)
+{
+	struct blockdev_core_entry *entry = NULL;
+
+	list_for_each_entry(entry, &core->succ, list) {
+		if (!index)
+			return entry->instance;
+		index--;
+	}
+
+	return NULL;
+}
+
+static int bind(struct core_instance *core, struct instance *dev, void

*ops, + void *data)

drivers/blockdev/core.c new file +37 -0

+{
+	struct blockdev_core_entry *entry;
+
+	if (ops == NULL)
+		return -EINVAL;
+
+	entry = malloc(sizeof(*entry));
+	if (entry == NULL)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&entry->list);
+	entry->instance = dev;
+	entry->ops = ops;
+	entry->name = create_id_from_hint(core, dev, data);
+	list_add_tail(&entry->list, &core->succ);
+
+	return 0;
+}
+
+static int unbind(struct core_instance *core, struct instance *dev)
+{
+	struct blockdev_core_entry *entry, *n;
+
+	list_for_each_entry_safe(entry, n, &core->succ, list) {
+		if (entry->instance == dev) {
+			list_del(&entry->list);
+			free(entry);
+		}
+	}
+
+	return 0;
+}
+
+static int replace(struct core_instance *core, struct instance *new,
+	struct instance *old)
+{
+	struct blockdev_core_entry *entry = get_entry_by_instance(old);

drivers/blockdev/core.c new file +52 -0

+{
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	return 0;
+}
+
+static int reloc(struct core_instance *core, struct core_instance *old)
+{
+	struct blockdev_core_entry *entry, *new;
+
+	/* no private_data to copy, yet */
+
+	/* fixup links in old list and prepare new list head */
+	/* FIXME */
+	/* list_fix_reloc(&old->succ); */
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	/* copy list entries to new memory */
+	list_for_each_entry(entry, &old->succ, list) {
+		new = malloc(sizeof(*new));
+		if (!new)
+			return -ENOMEM;
+
+		INIT_LIST_HEAD(&new->list);
+		new->instance = entry->instance;
+		new->ops = entry->ops;
+		new->name = entry->name;
+		list_add_tail(&new->list, &core->succ);
+		/*no free at this point, old memory should not be freed*/
+	}
+
+	return 0;
+}
+
+static int destroy(struct core_instance *core)
+{
+	struct blockdev_core_entry *entry, *n;
+
+	/* destroy private data */
+	free(core->private_data);
+	core->private_data = NULL;
+
+	/* destroy successor list */
+	list_for_each_entry_safe(entry, n, &core->succ, list) {
+		list_del(&entry->list);
+		free(entry);
+	}
+
+	return 0;
+}

(quoted diff) +2 -0

+/* Driver wrapping API */
+lbaint_t blockdev_read(struct instance *i, lbaint_t start, lbaint_t

blkcnt, + void *buffer)

drivers/blockdev/core.c new file +21 -0

+{
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)
+		return error;
+
+	device_ops = entry->ops;
+	if (!device_ops || !device_ops->read)
+		return -EINVAL;
+
+	return device_ops->read(i, start, blkcnt, buffer);
+}
+
+lbaint_t blockdev_write(struct instance *i, lbaint_t start, lbaint_t

blkcnt, + void *buffer)

drivers/blockdev/core.c new file +21 -0

+{
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)
+		return error;
+
+	device_ops = entry->ops;
+	if (!device_ops || !device_ops->write)
+		return -EINVAL;
+
+	return device_ops->write(i, start, blkcnt, buffer);
+}
+
+lbaint_t blockdev_erase(struct instance *i, lbaint_t start, lbaint_t

blkcnt) +{

drivers/blockdev/core.c new file +115 -0

+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)
+		return error;
+
+	device_ops = entry->ops;
+	if (!device_ops)
+		return -EINVAL;
+
+	return device_ops->erase(i, start, blkcnt);
+}
+
+int blockdev_get_option(struct instance *i, enum blockdev_option_code op,
+	struct option *result)
+{
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)
+		return error;
+
+	device_ops = entry->ops;
+	if (!device_ops)
+		return -EINVAL;
+
+	return device_ops->get_option(i, op, result);
+}
+
+int blockdev_set_option(struct instance *i, enum blockdev_option_code op,
+	struct option *value)
+{
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)
+		return error;
+
+	device_ops = entry->ops;
+	if (!device_ops)
+		return -EINVAL;
+
+	return device_ops->set_option(i, op, value);
+}
+
+/* Command related functions */
+struct instance *get_blockdev_by_name(char *name)
+{
+	struct blockdev_id disk_id = empty_id;
+	struct blockdev_core_entry *entry;
+
+	if (!name)
+		return NULL;
+
+	disk_id = get_id_from_name(name);
+
+	if (id_cmp(&disk_id, &invalid_id)) {
+		entry = get_entry_by_id(disk_id);
+		if (entry)
+			return entry->instance;
+	}
+
+	return NULL;
+}
+
+int scan_partitions(struct instance *dev)
+{
+	struct blockdev_core_entry *entry;
+	struct driver_instance *di, *tmp;
+
+	entry = get_entry_by_instance(dev);
+	/* ignore if instance is partition or not a blockdev */
+	if (!entry || (entry->name.partition != 0))
+		return -EINVAL;
+
+	/* remove all children */
+	list_for_each_entry_safe(di, tmp, &dev->succ, list) {
+		driver_remove(&di->i);
+		driver_unbind(&di->i);
+	}
+
+	/* determine type of partition table and scan for partitions */
+#ifdef CONFIG_DOS_PARTITION
+	if (!test_partitions_dos(dev))
+		return scan_partitions_dos(dev);
+#endif
+
+	return -ENOENT;
+}
+
+static inline int part_number_overflow(int number)
+{
+	/* just support 128 partitions for now */
+	return (number > 128);
+}
+
+int add_partition(struct instance *parent, lbaint_t start, lbaint_t

length, + unsigned int number)

drivers/blockdev/core.c new file +48 -0

+{
+	struct blockdev_partition_platform_data *platform = NULL;
+	struct driver_info *info = NULL;
+
+	/* check for overflow in partition number */
+	if (part_number_overflow(number))
+		return -EINVAL;
+
+	platform = malloc(sizeof(*platform));
+	info = malloc(sizeof(*info));
+	if (!platform || !info) {
+		/* malloc went wrong, cleanup and indicate imminent death */
+		free(platform);
+		free(info);
+		return -ENOMEM;
+	}
+
+	platform->offset = start;
+	platform->block_count = length;
+	platform->part_number = number;
+	info->name = "blockdev_partition";
+	info->platform_data = platform;
+	if (!driver_bind(parent, info))
+		return -ENOMEM;
+
+	return 0;
+}
+
+/* Info printing stuff */
+static char *type_name(unsigned type)
+{
+	switch (type) {
+	case BLOCKDEV_TYPE_UNKNOWN:
+		return "Unknown/Not Connected";
+	case BLOCKDEV_TYPE_HARDDISK:
+		return "Hard drive";
+	case BLOCKDEV_TYPE_TAPE:
+		return "Tape";
+	case BLOCKDEV_TYPE_CDROM:
+		return "CDROM";
+	case BLOCKDEV_TYPE_OPDISK:
+		return "Optical disk";
+	default:
+		return "Unknown";
+	};
+}
+
+static inline int get_opt_u(struct blockdev_ops *ops, struct instance

*dev, + enum blockdev_option_code code, struct option *opt)

drivers/blockdev/core.c new file +17 -0

+{
+	int retval = ops->get_option(dev, code, opt);
+	if (retval)
+		return retval;
+
+	/* If we dont get the correct type we fail. */
+	if (OPTION_TYPE(*opt) != OPTION_TYPE_U)
+		retval = -EINVAL;
+
+	/* If we get a mallocated string we should free it. */
+	if (opt->flags & OPTION_PTR_MALLOCED)
+		free(opt->data.data_s);
+
+	return retval;
+}
+
+static inline int get_opt_s(struct blockdev_ops *ops, struct instance

*dev, + enum blockdev_option_code code, struct option *opt)

drivers/blockdev/core.c new file +175 -0

+{
+	int retval = ops->get_option(dev, code, opt);
+	if (retval)
+		return retval;
+
+	/* If we dont get the correct type we fail. */
+	if (OPTION_TYPE(*opt) != OPTION_TYPE_S)
+		retval = -EINVAL;
+
+	return retval;
+}
+
+int print_blockdev_info(struct instance *dev)
+{
+	struct option opt;
+	unsigned int type = 0;
+	unsigned int block_size = 0;
+	lbaint_t offset = 0;
+	lbaint_t block_count = 0;
+	char *vendor = NULL;
+	char *product = NULL;
+	char *revision = NULL;
+	int vendor_malloc = 0;
+	int product_malloc = 0;
+	int revision_malloc = 0;
+	struct blockdev_id id = empty_id;
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *ops = NULL;
+	int retval = 0;
+	enum blockdev_iftype iftype;
+
+	entry = get_entry_by_instance(dev);
+	if (!entry)
+		return -ENOENT;
+	else {
+		id = entry->name;
+		ops = entry->ops;
+	}
+
+	/* we are not using blockdev_get_option, so we activate manually here */
+	retval = driver_activate(dev);
+	if (retval)
+		return retval;
+
+	retval = get_opt_u(ops, dev, BLKD_OPT_TYPE, &opt);
+	if (retval)
+		return retval;
+	type = opt.data.data_u;
+
+	if (type == BLOCKDEV_TYPE_PARTITION) {
+		/* get options that make sense for a partition */
+		retval = get_opt_u(ops, dev, BLKD_OPT_BLOCKCOUNT, &opt);
+		if (retval)
+			return retval;
+		block_count = opt.data.data_u;
+
+		retval = get_opt_u(ops, dev, BLKD_OPT_OFFSET, &opt);
+		if (retval)
+			return retval;
+		offset = opt.data.data_u;
+
+		/* print some information message */
+		printf("%s%d:%d\n\tpartition on %s%d\n\t"
+			"offset: %lu\n\tblock count: %lu\n\n",
+			blockdev_name[id.disk.type], id.disk.number,
+			id.partition, blockdev_name[id.disk.type],
+			id.disk.number, offset, block_count);
+
+	} else {
+		/* get options that make sense for a disk */
+		retval = get_opt_u(ops, dev, BLKD_OPT_IFTYPE, &opt);
+		if (retval)
+			return retval;
+		iftype = opt.data.data_u;
+
+		retval = get_opt_u(ops, dev, BLKD_OPT_BLOCKSIZE, &opt);
+		if (retval)
+			return retval;
+		block_size = opt.data.data_u;
+
+		retval = get_opt_u(ops, dev, BLKD_OPT_BLOCKCOUNT, &opt);
+		if (retval)
+			return retval;
+		block_count = opt.data.data_u;
+
+		retval = get_opt_s(ops, dev, BLKD_OPT_VENDOR, &opt);
+		if (retval)
+			return retval;
+		vendor = opt.data.data_s;
+		vendor_malloc = opt.flags & OPTION_PTR_MALLOCED;
+
+		retval = get_opt_s(ops, dev, BLKD_OPT_PRODUCT, &opt);
+		if (retval)
+			return retval;
+		product = opt.data.data_s;
+		product_malloc = opt.flags & OPTION_PTR_MALLOCED;
+
+		retval = get_opt_s(ops, dev, BLKD_OPT_REVISION, &opt);
+		if (retval)
+			return retval;
+		revision = opt.data.data_s;
+		revision_malloc = opt.flags & OPTION_PTR_MALLOCED;
+
+		/* print some information message */
+		printf("%s%d\n\tvendor: %s\n\tproduct: %s\n\t"
+			"revision: %s\n\ttype: %s\n\tiftype: %s\n\t"
+			"block size: %d\n\tblock count: %lu\n\n",
+			blockdev_name[id.disk.type], id.disk.number,
+			vendor, product, revision, type_name(type),
+			iftype_name[iftype], block_size, block_count);
+
+		/*cleanup if we got dynamic memory pointers*/
+		if (vendor_malloc)
+			free(vendor);
+
+		if (product_malloc)
+			free(product);
+
+		if (revision_malloc)
+			free(revision);
+	}
+
+	return retval;
+}
+
+static void sort_bdid_i(struct bdid_instance_pair *data, size_t count)
+{
+	/* use bubble sort for now */
+	int a, b;
+	struct bdid_instance_pair tswap;
+
+	for (a = 1; a < count; a++) {
+		for (b = a; b > 0; b--) {
+			if (id_cmp(&data[b].id, &data[b-1].id) < 0) {
+				/*swap position b and b-1 */
+				tswap = data[b-1];
+				data[b-1] = data[b];
+				data[b] = tswap;
+			}
+		}
+	}
+}
+
+int print_blockdev_info_all(void)
+{
+	struct core_instance *core = NULL;
+	struct bdid_instance_pair *sorted_pairs = NULL;
+	struct blockdev_core_entry *entry = NULL;
+	int count = 0;
+	int idx = 0;
+
+	core = get_core_instance(CORE_BLOCKDEV);
+	if (!core)
+		return -ENOMEM;
+
+	count = core_get_count(CORE_BLOCKDEV);
+	sorted_pairs = malloc(sizeof(*sorted_pairs) * count);
+	if (!sorted_pairs)
+		return -ENOMEM;
+
+	/* get list of all instances and associated IDs */
+	list_for_each_entry(entry, &core->succ, list) {
+		sorted_pairs[idx].id = entry->name;
+		sorted_pairs[idx].inst = entry->instance;
+		idx++;
+	}
+
+	/* sort isntances by ID */
+	sort_bdid_i(sorted_pairs, count);
+
+	/* print info about each instance */
+	for (idx = 0; idx < count; idx++)
+		print_blockdev_info(sorted_pairs[idx].inst);
+	return 0;
+}

(quoted diff) +0 -0

b/drivers/blockdev/part_types/part_dos.c new file mode 100644 index 0000000..7d19818

drivers/blockdev/part_types/part_dos.c new file +30 -0

@@ -0,0 +1,148 @@
+/*
+ * (C) Copyright 2001
+ * Raymond Lo, lo at routefree.com
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * Support for harddisk partitions.
+ *
+ * To be compatible with LinuxPPC and Apple we use the standard Apple
+ * SCSI disk partitioning scheme. For more information see:
+ *

http://developer.apple.com/techpubs/mac/Devices/Devices-126.html#MARKER-14
-92 + */

drivers/blockdev/part_types/part_dos.c new file +117 -0

+
+#include <common.h>
+#include <ide.h>
+#include "part_dos.h"
+#include <dm/blockdev.h>
+
+#if defined(CONFIG_CMD_IDE) || \
+	defined(CONFIG_CMD_MG_DISK) || \
+	defined(CONFIG_CMD_SATA) || \
+	defined(CONFIG_CMD_SCSI) || \
+	defined(CONFIG_CMD_USB) || \
+	defined(CONFIG_MMC) || \
+	defined(CONFIG_SYSTEMACE)
+
+/* Convert char[4] in little endian format to the host format integer
+ */
+static inline int le32_to_int(unsigned char *le32)
+{
+	return ((le32[3] << 24) +
+		(le32[2] << 16) +
+		(le32[1] << 8) +
+		le32[0]);
+}
+
+static inline int is_extended(int part_type)
+{
+	return (part_type == 0x5 ||
+		part_type == 0xf ||
+		part_type == 0x85);
+}
+
+int test_partitions_dos(struct instance *dev)
+{
+	struct option blksz;
+	int error = blockdev_get_option(dev, BLKD_OPT_BLOCKSIZE, &blksz);
+	if (error)
+		return error;
+
+	ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, blksz.data.data_u);
+
+	if ((blockdev_read(dev, 0, 1, buffer) != 1) ||
+	    (buffer[DOS_PART_MAGIC_OFFSET + 0] != 0x55) ||
+	    (buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa)) {
+		return -EINVAL;
+	}
+	return 0;
+}
+
+
+
+int scan_partitions_dos(struct instance *dev)
+{
+	struct dos_partition *pt;
+	lbaint_t extpt_sector = 0;
+	struct option blksz;
+	int error = blockdev_get_option(dev, BLKD_OPT_BLOCKSIZE, &blksz);
+	if (error)
+		return error;
+
+	ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, blksz.data.data_u);
+
+	if (blockdev_read(dev, 0, 1, buffer) != 1) {
+		printf("** Can't read partition table **\n");
+		return -EINVAL;
+	}
+
+	if (buffer[DOS_PART_MAGIC_OFFSET] != 0x55 ||
+		buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) {
+		printf("bad MBR sector signature 0x%02x%02x\n",
+			buffer[DOS_PART_MAGIC_OFFSET],
+			buffer[DOS_PART_MAGIC_OFFSET + 1]);
+		return -EINVAL;
+	}
+
+	pt = (struct dos_partition *) (buffer + DOS_PART_TBL_OFFSET);
+	int i;
+	for (i = 0; i < 4; i++, pt++) {
+		if (((pt->boot_ind & ~0x80) == 0) &&
+				(pt->sys_ind != 0) &&
+				(is_extended(pt->sys_ind) == 0)) {
+			add_partition(dev, le32_to_int(pt->start4),
+				le32_to_int(pt->size4), i+1);
+		}
+		if (is_extended(pt->sys_ind))
+			extpt_sector = le32_to_int(pt->start4);
+	}
+
+	if (extpt_sector == 0)
+		return 0;
+
+	/* repeat once for extended partitions */
+	if (blockdev_read(dev, extpt_sector, 1, buffer) != 1) {
+		printf("** Can't read extended partition table **\n");
+		return -EINVAL;
+	}
+
+	if (buffer[DOS_PART_MAGIC_OFFSET] != 0x55 ||
+		buffer[DOS_PART_MAGIC_OFFSET + 1] != 0xaa) {
+		printf("bad MBR sector signature 0x%02x%02x\n",
+			buffer[DOS_PART_MAGIC_OFFSET],
+			buffer[DOS_PART_MAGIC_OFFSET + 1]);
+		return -EINVAL;
+	}
+
+	pt = (struct dos_partition *) (buffer + DOS_PART_TBL_OFFSET);
+	for (i = 0; i < 4; i++, pt++) {
+		if (((pt->boot_ind & ~0x80) == 0) &&
+				(pt->sys_ind != 0) &&
+				(is_extended(pt->sys_ind) == 0)) {
+			add_partition(dev, le32_to_int(pt->start4),
+				le32_to_int(pt->size4), i+5);
+		}
+	}
+
+	return 0;
+}
+#endif

(quoted diff) +0 -0

b/drivers/blockdev/part_types/part_dos.h new file mode 100644 index 0000000..98b0293

drivers/blockdev/part_types/part_dos.h new file +49 -0

@@ -0,0 +1,49 @@
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _DISK_PART_DOS_H
+#define _DISK_PART_DOS_H
+
+
+#define DOS_PART_TBL_OFFSET	0x1be
+#define DOS_PART_MAGIC_OFFSET	0x1fe
+#define DOS_PBR_FSTYPE_OFFSET	0x36
+#define DOS_PBR32_FSTYPE_OFFSET	0x52
+#define DOS_PBR_MEDIA_TYPE_OFFSET	0x15
+#define DOS_MBR	0
+#define DOS_PBR	1
+
+struct dos_partition {
+	unsigned char boot_ind;		/* 0x80 - active		*/
+	unsigned char head;		/* starting head		*/
+	unsigned char sector;		/* starting sector		*/
+	unsigned char cyl;		/* starting cylinder		*/
+	unsigned char sys_ind;		/* What partition type		*/
+	unsigned char end_head;		/* end head			*/
+	unsigned char end_sector;	/* end sector			*/
+	unsigned char end_cyl;		/* end cylinder			*/
+	unsigned char start4[4];	/* starting sector counting from 0*/
+	unsigned char size4[4];		/* nr of sectors in partition	*/
+};
+
+#endif	/* _DISK_PART_DOS_H */

(quoted diff) +0 -0

b/drivers/blockdev/part_types/part_types.h new file mode 100644 index 0000000..d5e6f61

drivers/blockdev/part_types/part_types.h new file +34 -0

@@ -0,0 +1,34 @@
+/*
+ * (C) Copyright 2012
+ * Pavel Herrmann <[email protected]>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _BLOCKDEV_PART_TYPES_H_
+#define _BLOCKDEV_PART_TYPES_H_ 1
+
+#include <dm/structures.h>
+
+#ifdef CONFIG_DOS_PARTITION
+int test_partitions_dos(struct instance *i);
+int scan_partitions_dos(struct instance *i);
+#endif
+
+#endif

Dear Pavel Herrmann,

[..]

drivers/blockdev/core.c line 37

Quoted 3 lines

drivers/blockdev/core.c new file +3 -0

+#define BLOCKDEV_IFTYPE_BITS 4
+#define BLOCKDEV_IFTYPE_COUNT (1<<BLOCKDEV_IFTYPE_BITS)
+#define BLOCKDEV_IFTYPE_MAX BLOCKDEV_IFTYPE_COUNT-1

I saw this in blockdev.h

Quoted 11 lines

drivers/blockdev/core.c new file +11 -0

+}
+
+static int replace(struct core_instance *core, struct instance *new,
+	struct instance *old)
+{
+	struct blockdev_core_entry *entry = get_entry_by_instance(old);
+
+	if (!entry)
+		return -ENOENT;
+
+	entry->instance = new;

drivers/blockdev/core.c line 284

Quoted 5 lines

drivers/blockdev/core.c new file +5 -0

+
+	return 0;
+}
+
+static int init(struct core_instance *core)

I'd say, rename it to block_core_init() or something, so the syms in u-boot.map are unique.

Quoted 57 lines

drivers/blockdev/core.c new file +57 -0

+{
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	return 0;
+}
+
+static int reloc(struct core_instance *core, struct core_instance *old)
+{
+	struct blockdev_core_entry *entry, *new;
+
+	/* no private_data to copy, yet */
+
+	/* fixup links in old list and prepare new list head */
+	/* FIXME */
+	/* list_fix_reloc(&old->succ); */
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	/* copy list entries to new memory */
+	list_for_each_entry(entry, &old->succ, list) {
+		new = malloc(sizeof(*new));
+		if (!new)
+			return -ENOMEM;
+
+		INIT_LIST_HEAD(&new->list);
+		new->instance = entry->instance;
+		new->ops = entry->ops;
+		new->name = entry->name;
+		list_add_tail(&new->list, &core->succ);
+		/*no free at this point, old memory should not be freed*/
+	}
+
+	return 0;
+}
+
+static int destroy(struct core_instance *core)
+{
+	struct blockdev_core_entry *entry, *n;
+
+	/* destroy private data */
+	free(core->private_data);
+	core->private_data = NULL;
+
+	/* destroy successor list */
+	list_for_each_entry_safe(entry, n, &core->succ, list) {
+		list_del(&entry->list);
+		free(entry);
+	}
+
+	return 0;
+}
+
+U_BOOT_CORE(CORE_BLOCKDEV,
+	init,
+	reloc,
+	destroy,

drivers/blockdev/core.c line 346

Quoted 5 lines

drivers/blockdev/core.c new file +5 -0

+	get_count,
+	get_child,
+	bind,
+	unbind,
+	replace);

Sep the stuff below away into separate file. Conditionally compile in one or the other.

Quoted 14 lines

(quoted diff) +2 -0

+/* Driver wrapping API */
+lbaint_t blockdev_read(struct instance *i, lbaint_t start, lbaint_t

blkcnt, + void *buffer)

drivers/blockdev/core.c new file +11 -0

+{
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)

drivers/blockdev/core.c line 369

Quoted 8 lines

drivers/blockdev/core.c new file +8 -0

+		return error;
+
+	device_ops = entry->ops;
+	if (!device_ops || !device_ops->read)
+		return -EINVAL;
+
+	return device_ops->read(i, start, blkcnt, buffer);
+}

Quoted 4 lines

Quoted 1 line

+static int init(struct core_instance *core)

I'd say, rename it to block_core_init() or something, so the syms in u-boot.map are unique.

thic being static, how could it show in u-boot.map?

Quoted 57 lines

Quoted 57 lines

drivers/blockdev/core.c new file +8 -0

+{
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	return 0;
+}
+
+static int reloc(struct core_instance *core, struct core_instance

*old) +{

drivers/blockdev/core.c new file +48 -0

+	struct blockdev_core_entry *entry, *new;
+
+	/* no private_data to copy, yet */
+
+	/* fixup links in old list and prepare new list head */
+	/* FIXME */
+	/* list_fix_reloc(&old->succ); */
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	/* copy list entries to new memory */
+	list_for_each_entry(entry, &old->succ, list) {
+		new = malloc(sizeof(*new));
+		if (!new)
+			return -ENOMEM;
+
+		INIT_LIST_HEAD(&new->list);
+		new->instance = entry->instance;
+		new->ops = entry->ops;
+		new->name = entry->name;
+		list_add_tail(&new->list, &core->succ);
+		/*no free at this point, old memory should not be freed*/
+	}
+
+	return 0;
+}
+
+static int destroy(struct core_instance *core)
+{
+	struct blockdev_core_entry *entry, *n;
+
+	/* destroy private data */
+	free(core->private_data);
+	core->private_data = NULL;
+
+	/* destroy successor list */
+	list_for_each_entry_safe(entry, n, &core->succ, list) {
+		list_del(&entry->list);
+		free(entry);
+	}
+
+	return 0;
+}
+
+U_BOOT_CORE(CORE_BLOCKDEV,
+	init,
+	reloc,
+	destroy,

Quoted 8 lines

drivers/blockdev/core.c line 346

Quoted 5 lines

drivers/blockdev/core.c new file +5 -0

+	get_count,
+	get_child,
+	bind,
+	unbind,
+	replace);

Sep the stuff below away into separate file. Conditionally compile in one or the other.

I distinctly remember you saying to put all this into one file (as opposed to 3 it was before), so why the turn-around now?

No idea what you mean by "one or the other" - you need all this code for it to work.

Quoted 16 lines

Quoted 16 lines

(quoted diff) +2 -0

+/* Driver wrapping API */
+lbaint_t blockdev_read(struct instance *i, lbaint_t start, lbaint_t

blkcnt, + void *buffer)

drivers/blockdev/core.c new file +13 -0

+{
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)
+		return error;
+

Quoted 6 lines

drivers/blockdev/core.c line 369

Quoted 6 lines

drivers/blockdev/core.c new file +6 -0

+	device_ops = entry->ops;
+	if (!device_ops || !device_ops->read)
+		return -EINVAL;
+
+	return device_ops->read(i, start, blkcnt, buffer);
+}

Pavel Herrmann

Dear Pavel Herrmann,

[...]

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

+static int init(struct core_instance *core)

Quoted 4 lines

Quoted 2 lines

I'd say, rename it to block_core_init() or something, so the syms in u-boot.map are unique.

thic being static, how could it show in u-boot.map?

Argh, not u-boot.map, sorry. But it's much easier for git grep to look up unique syms than this.

Quoted 67 lines

Quoted 58 lines

Quoted 58 lines

drivers/blockdev/core.c new file +8 -0

+{
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	return 0;
+}
+
+static int reloc(struct core_instance *core, struct core_instance

*old) +{

drivers/blockdev/core.c new file +49 -0

+	struct blockdev_core_entry *entry, *new;
+
+	/* no private_data to copy, yet */
+
+	/* fixup links in old list and prepare new list head */
+	/* FIXME */
+	/* list_fix_reloc(&old->succ); */
+	INIT_LIST_HEAD(&core->succ);
+	core->private_data = NULL;
+
+	/* copy list entries to new memory */
+	list_for_each_entry(entry, &old->succ, list) {
+		new = malloc(sizeof(*new));
+		if (!new)
+			return -ENOMEM;
+
+		INIT_LIST_HEAD(&new->list);
+		new->instance = entry->instance;
+		new->ops = entry->ops;
+		new->name = entry->name;
+		list_add_tail(&new->list, &core->succ);
+		/*no free at this point, old memory should not be freed*/
+	}
+
+	return 0;
+}
+
+static int destroy(struct core_instance *core)
+{
+	struct blockdev_core_entry *entry, *n;
+
+	/* destroy private data */
+	free(core->private_data);
+	core->private_data = NULL;
+
+	/* destroy successor list */
+	list_for_each_entry_safe(entry, n, &core->succ, list) {
+		list_del(&entry->list);
+		free(entry);
+	}
+
+	return 0;
+}
+
+U_BOOT_CORE(CORE_BLOCKDEV,
+	init,
+	reloc,
+	destroy,
+	get_count,

Quoted 8 lines

drivers/blockdev/core.c line 346

Quoted 4 lines

drivers/blockdev/core.c new file +4 -0

+	get_child,
+	bind,
+	unbind,
+	replace);

Sep the stuff below away into separate file. Conditionally compile in one
or the other.

Quoted 2 lines

I distinctly remember you saying to put all this into one file (as opposed to 3 it was before), so why the turn-around now?

Well, I didn't see the code before, so I couldn't make a firm decision, sorry.

Quoted 3 lines

No idea what you mean by "one or the other" - you need all this code for it
to work.

You need the "driver wrapping API" if DM is enabled? I do not understand this, please elaborate!

What about having a common part for both cases and then compile either the DM part or non-DM part conditionally?

Quoted 16 lines

Quoted 16 lines

Quoted 16 lines

(quoted diff) +2 -0

+/* Driver wrapping API */
+lbaint_t blockdev_read(struct instance *i, lbaint_t start, lbaint_t

blkcnt, + void *buffer)

drivers/blockdev/core.c new file +13 -0

+{
+	struct blockdev_core_entry *entry = NULL;
+	struct blockdev_ops *device_ops = NULL;
+	int error;
+
+	entry = get_entry_by_instance(i);
+	if (!entry)
+		return -ENOENT;
+
+	error = driver_activate(i);
+	if (error)
+		return error;
+

Quoted 8 lines

Quoted 6 lines

drivers/blockdev/core.c line 369

Quoted 6 lines

drivers/blockdev/core.c new file +6 -0

+	device_ops = entry->ops;
+	if (!device_ops || !device_ops->read)
+		return -EINVAL;
+
+	return device_ops->read(i, start, blkcnt, buffer);
+}

Pavel Herrmann

Best regards,
Marek Vasut

Quoted 5 lines

You need the "driver wrapping API" if DM is enabled? I do not understand this, please elaborate!

What about having a common part for both cases and then compile either the DM part or non-DM part conditionally?

this is all DM-only.
driver-wrapping API is wrapper/proxy functions to driver ops (aka it wraps around the ops, doing lookup and activate and whatnot), not a wrapper for old API (which would be in a driver mind you)

This core provides unified access to different block controllers (SATA, SCSI).

Signed-off-by Pavel Herrmann <[email protected]>

---
 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349
+++++++++++++++++++++++++++++++++++++++++++++ include/dm/blockctrl.h     |
 75 ++++++++++
 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644

Dear Pavel Herrmann,

Quoted 2 lines

This core provides unified access to different block controllers (SATA, SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 20 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++ include/dm/blockctrl.h |

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644

Makefile LIBS-y += test/libtest.o · line 309

Quoted 6 lines

Makefile +1 -0

@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 
 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 
+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

[..]

This handles SCSI? Sata ? what ?

Should this not be called scsi_core ? sata_core ? What did the previous core do? sata? scsi? block? I'm lost.

I stop here, I don't know what this is all about, sorry.

Best regards,
Marek Vasut

Quoted 30 lines

Dear Pavel Herrmann,

Quoted 2 lines

This core provides unified access to different block controllers (SATA, SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 22 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++ include/dm/blockctrl.h
|

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644
@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 

Quoted 7 lines

Makefile LIBS-y += test/libtest.o

Quoted 5 lines

Makefile +1 -0

 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 
+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

Quoted 6 lines

[..]

This handles SCSI? Sata ? what ?

Should this not be called scsi_core ? sata_core ? What did the previous core do? sata? scsi? block? I'm lost.

the previous core handled disks (and cards and stuff) and partitions (think /dev/sdxy), and was largely a replacement of /disk
this core handles any interface those disks are connected to (SATA, PATA, SCSI), and should replace /drivers/block

Quoted 4 lines

I stop here, I don't know what this is all about, sorry.

Best regards,
Marek Vasut

Dear Pavel Herrmann,

Quoted 31 lines · On Thursday 20 of September 2012 22:05:36 Marek Vasut wrote:

Quoted 30 lines

Dear Pavel Herrmann,

Quoted 3 lines

This core provides unified access to different block controllers (SATA,
SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 21 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++ include/dm/blockctrl.h

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644
@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 

Quoted 7 lines

Quoted 7 lines

Makefile LIBS-y += test/libtest.o

Quoted 5 lines

Makefile +1 -0

 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 
+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

Why not just reuse drivers/block and in drivers/block compile in the libblock.o so you don't polute the top-level makefile ? Easy as that.

Quoted 4 lines

Quoted 4 lines

[..]

This handles SCSI? Sata ? what ?

Quoted 8 lines

Quoted 2 lines

Should this not be called scsi_core ? sata_core ? What did the previous core do? sata? scsi? block? I'm lost.

the previous core handled disks (and cards and stuff) and partitions (think
/dev/sdxy), and was largely a replacement of /disk
this core handles any interface those disks are connected to (SATA, PATA, SCSI), and should replace /drivers/block

Why is this not in the commit message then ? I have a proposal, before you submit a patchset, prepare it, work on something else for a bit, then read again the commit message only and see if you still understand what it means.

Am I correct that this will look as such:
user -> [ 01/11 ] -> [ 03/11 or something else ] -> [ if 03/11, then disc ]

Quoted 58 lines

Dear Pavel Herrmann,

Quoted 32 lines · On Thursday 20 of September 2012 22:05:36 Marek Vasut wrote:

Quoted 31 lines

Dear Pavel Herrmann,

Quoted 3 lines

This core provides unified access to different block controllers (SATA,
SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 22 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++
include/dm/blockctrl.h

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644
@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 

Quoted 7 lines

Quoted 7 lines

Makefile LIBS-y += test/libtest.o

Quoted 5 lines

Makefile +1 -0

 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 
+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

Why not just reuse drivers/block and in drivers/block compile in the libblock.o so you don't polute the top-level makefile ? Easy as that.

Quoted 12 lines

Quoted 6 lines

[..]

This handles SCSI? Sata ? what ?

Should this not be called scsi_core ? sata_core ? What did the previous core do? sata? scsi? block? I'm lost.

the previous core handled disks (and cards and stuff) and partitions (think
/dev/sdxy), and was largely a replacement of /disk
this core handles any interface those disks are connected to (SATA, PATA, SCSI), and should replace /drivers/block

Quoted 4 lines

Why is this not in the commit message then ? I have a proposal, before you submit a patchset, prepare it, work on something else for a bit, then read again the commit message only and see if you still understand what it means.

I actually did. the "something else" was splitting it into smaller patches,

so the original text information got distributed into the other patches. if i put it all here you would surely complain about it not being there, or it being duplicated

Quoted 3 lines

Am I correct that this will look as such:
user -> [ 01/11 ] -> [ 03/11 or something else ] -> [ if 03/11, then disc ]

no idea what this means, sorry

Pavel Herrmann

Dear Pavel Herrmann,

Quoted 64 lines · On Friday 21 of September 2012 14:51:33 Marek Vasut wrote:

Quoted 62 lines

Dear Pavel Herrmann,

Quoted 32 lines · On Thursday 20 of September 2012 22:05:36 Marek Vasut wrote:

Quoted 31 lines

Dear Pavel Herrmann,

Quoted 3 lines

This core provides unified access to different block controllers (SATA,
SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 22 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++
include/dm/blockctrl.h

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644
@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 

Quoted 7 lines

Quoted 7 lines

Makefile LIBS-y += test/libtest.o

Quoted 5 lines

Makefile +1 -0

 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 
+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

Why not just reuse drivers/block and in drivers/block compile in the libblock.o so you don't polute the top-level makefile ? Easy as that.

Quoted 4 lines

Quoted 4 lines

[..]

This handles SCSI? Sata ? what ?

Quoted 8 lines

Quoted 2 lines

Should this not be called scsi_core ? sata_core ? What did the previous core do? sata? scsi? block? I'm lost.

the previous core handled disks (and cards and stuff) and partitions (think
/dev/sdxy), and was largely a replacement of /disk
this core handles any interface those disks are connected to (SATA, PATA, SCSI), and should replace /drivers/block

Why is this not in the commit message then ? I have a proposal, before you submit a patchset, prepare it, work on something else for a bit, then read again the commit message only and see if you still understand what it means.

Quoted 2 lines

I actually did. the "something else" was splitting it into smaller patches,

I mean something totally different, so you won't have the code in front of you. You DO understand the code because you wrote it, you need to work on the part where you explain others properly what your change does. Even if it mean writing essay-esque commit message.

Quoted 3 lines

so the original text information got distributed into the other patches. if i put it all here you would surely complain about it not being there, or it being duplicated

Not really ...

Quoted 6 lines

Quoted 4 lines

Am I correct that this will look as such:
user -> [ 01/11 ] -> [ 03/11 or something else ] -> [ if 03/11, then disc
]

no idea what this means, sorry

Patch numbers, how the code added in them connect into each other.

Dear Pavel Herrmann,

Quoted 35 lines · On Thursday 20 of September 2012 22:05:36 Marek Vasut wrote:

Quoted 34 lines

Dear Pavel Herrmann,

Quoted 3 lines

This core provides unified access to different block controllers (SATA,
SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 25 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++ include/dm/blockctrl.h

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644
@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 
 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 

Quoted 3 lines

Quoted 3 lines

Makefile LIBS-y += test/libtest.o · line 307

Quoted 1 line

Makefile +1 -0

+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

Why not just reuse drivers/block and in drivers/block compile in the libblock.o so you don't polute the top-level makefile ? Easy as that.

Quoted 42 lines

Dear Pavel Herrmann,

Quoted 39 lines · On Thursday 20 of September 2012 22:05:36 Marek Vasut wrote:

Quoted 38 lines

Dear Pavel Herrmann,

Quoted 3 lines

This core provides unified access to different block controllers (SATA,
SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 21 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++
include/dm/blockctrl.h

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644

Makefile LIBS-y += test/libtest.o · line 309

Quoted 6 lines

Makefile +1 -0

@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 
 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 
+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

Quoted 2 lines

Why not just reuse drivers/block and in drivers/block compile in the libblock.o so you don't polute the top-level makefile ? Easy as that.

to make a distinction between drivers that are converted to new API and those that are not, and to enable drivers to have the same filename for original and converted versions.

Pavel Herrmann

Dear Pavel Herrmann,

Quoted 43 lines · On Friday 21 of September 2012 14:51:33 Marek Vasut wrote:

Quoted 42 lines

Dear Pavel Herrmann,

Quoted 39 lines · On Thursday 20 of September 2012 22:05:36 Marek Vasut wrote:

Quoted 38 lines

Dear Pavel Herrmann,

Quoted 3 lines

This core provides unified access to different block controllers (SATA,
SCSI).

Description of the patch missing or is sub-par. You should work on this skill.

Quoted 21 lines

Signed-off-by Pavel Herrmann <[email protected]>

---

 Makefile                   |   1 +
 drivers/blockctrl/Makefile |  42 ++++++
 drivers/blockctrl/core.c   | 349

+++++++++++++++++++++++++++++++++++++++++++++
include/dm/blockctrl.h

75 ++++++++++

 4 files changed, 467 insertions(+)
 create mode 100644 drivers/blockctrl/Makefile
 create mode 100644 drivers/blockctrl/core.c
 create mode 100644 include/dm/blockctrl.h

Makefile +0 -0

index e43fd9d..4420484 100644

Makefile LIBS-y += test/libtest.o · line 309

Quoted 6 lines

Makefile +1 -0

@@ -304,6 +304,7 @@ LIBS-y += test/libtest.o
 
 LIBS-$(CONFIG_DM) += common/dm/libdm.o
 LIBS-$(CONFIG_DM) += drivers/demo/libdemo.o
 LIBS-${CONFIG_DM_BLOCK} += drivers/blockdev/libblockdev.o
 
+LIBS-${CONFIG_DM_BLOCK} += drivers/blockctrl/libblockctrl.o

${} ? What is this ?

Quoted 6 lines

Quoted 2 lines

Why not just reuse drivers/block and in drivers/block compile in the libblock.o so you don't polute the top-level makefile ? Easy as that.

to make a distinction between drivers that are converted to new API and those that are not, and to enable drivers to have the same filename for original and converted versions.

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ).
2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

How does that work? It's much cleaner.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Quoted 8 lines

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ).
2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

I actually did something of this sort, see [4/11], with less touching.

the problem is that while SATA drivers are easy to convert, IDE ones are not. I would actually propose to do a ide_legacy driver (mostly out of the code currently in common/cmd_ide.c), and keep it as the only option until IDE dies completely.

Quoted 6 lines

How does that work? It's much cleaner.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Dear Pavel Herrmann,

[...]

Quoted 9 lines

Quoted 8 lines

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ).
2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

Quoted 6 lines

I actually did something of this sort, see [4/11], with less touching.

the problem is that while SATA drivers are easy to convert, IDE ones are not. I would actually propose to do a ide_legacy driver (mostly out of the code currently in common/cmd_ide.c), and keep it as the only option until IDE dies completely.

IDE will be around for a LONG time.

You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you did it as said above, simple CONFIG_DM would suffice as the drivers would be intacts with DM disabled. Note the compiler will opt-out these proxy calls.

Besides, with this approach of yours, you need to enable SATA_LEGACY for every single board now, introducing a lot of churn into the patches and if it's not defined, every board using SATA is broken, right?

Quoted 6 lines

Quoted 6 lines

How does that work? It's much cleaner.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Quoted 27 lines

Dear Pavel Herrmann,

[...]

Quoted 9 lines

Quoted 8 lines

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ). 2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

Quoted 6 lines

I actually did something of this sort, see [4/11], with less touching.

the problem is that while SATA drivers are easy to convert, IDE ones are not. I would actually propose to do a ide_legacy driver (mostly out of the code currently in common/cmd_ide.c), and keep it as the only option until IDE dies completely.

IDE will be around for a LONG time.

You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you did it as said above, simple CONFIG_DM would suffice as the drivers would be intacts with DM disabled. Note the compiler will opt-out these proxy calls.

Quoted 3 lines

Besides, with this approach of yours, you need to enable SATA_LEGACY for every single board now, introducing a lot of churn into the patches and if it's not defined, every board using SATA is broken, right?

No, if you dont define CONFIG_DM, you get the old way of interacting with disks. only if you define CONFIG_DM you only need CONFIG_SATA_LEGACY to plug old SATA drivers into DM codepaths

Quoted 9 lines

Quoted 6 lines

Quoted 6 lines

How does that work? It's much cleaner.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Dear Pavel Herrmann,

Quoted 33 lines · On Friday 21 of September 2012 17:39:21 Marek Vasut wrote:

Quoted 31 lines

Dear Pavel Herrmann,

[...]

Quoted 9 lines

Quoted 8 lines

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ). 2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

Quoted 6 lines

I actually did something of this sort, see [4/11], with less touching.

the problem is that while SATA drivers are easy to convert, IDE ones are not. I would actually propose to do a ide_legacy driver (mostly out of the code currently in common/cmd_ide.c), and keep it as the only option until IDE dies completely.

IDE will be around for a LONG time.

You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you did it as
said above, simple CONFIG_DM would suffice as the drivers would be intacts with DM disabled. Note the compiler will opt-out these proxy calls.

Besides, with this approach of yours, you need to enable SATA_LEGACY for every single board now, introducing a lot of churn into the patches and if it's not defined, every board using SATA is broken, right?

Quoted 3 lines

No, if you dont define CONFIG_DM, you get the old way of interacting with disks. only if you define CONFIG_DM you only need CONFIG_SATA_LEGACY to plug old SATA drivers into DM codepaths

So if you enable DM for a board, you also need to enable this compat layer? My opinion is, that you either enable DM on the board and the board is ready for it or don't enable it.

Would you need the compat layer at all were you to follow my advice?

The whole idea goes deeper, see if you prepended this patchset with such a conversion as above, you'd already have a readily defined structure of blockdev operations in each driver to use in this patchset. This patchset would then really only be the DM stuff. The DM-part addition to the drivers would be mechanical.

Quoted 9 lines

Quoted 9 lines

Quoted 6 lines

Quoted 6 lines

How does that work? It's much cleaner.

Quoted 1 line

Pavel Herrmann

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Quoted 38 lines

Dear Pavel Herrmann,

Quoted 36 lines · On Friday 21 of September 2012 17:39:21 Marek Vasut wrote:

Quoted 34 lines

Dear Pavel Herrmann,

[...]

Quoted 10 lines

Quoted 9 lines

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ). 2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

Quoted 7 lines

I actually did something of this sort, see [4/11], with less touching.

the problem is that while SATA drivers are easy to convert, IDE ones are not. I would actually propose to do a ide_legacy driver (mostly out of the code currently in common/cmd_ide.c), and keep it as the only option until IDE dies completely.

IDE will be around for a LONG time.

You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you did it as
said above, simple CONFIG_DM would suffice as the drivers would be intacts with DM disabled. Note the compiler will opt-out these proxy calls.

Besides, with this approach of yours, you need to enable SATA_LEGACY for every single board now, introducing a lot of churn into the patches and if it's not defined, every board using SATA is broken, right?

Quoted 7 lines

Quoted 3 lines

No, if you dont define CONFIG_DM, you get the old way of interacting with disks. only if you define CONFIG_DM you only need CONFIG_SATA_LEGACY to plug old SATA drivers into DM codepaths

So if you enable DM for a board, you also need to enable this compat layer? My opinion is, that you either enable DM on the board and the board is ready for it or don't enable it.

if you enable DM on a board, you can either use the compat layer and the old driver, or use a ported driver and get rid of the compat layer

Quoted 1 line

Would you need the compat layer at all were you to follow my advice?

if i understand what you meant, i would build this compat layer into every one of the drivers currently in tree (with some cleanup). in that case, i would not need it

Quoted 10 lines

The whole idea goes deeper, see if you prepended this patchset with such a conversion as above, you'd already have a readily defined structure of blockdev operations in each driver to use in this patchset. This patchset would then really only be the DM stuff. The DM-part addition to the drivers would be mechanical.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

How does that work? It's much cleaner.

Quoted 1 line

Pavel Herrmann

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Dear Pavel Herrmann,

Quoted 52 lines · On Friday 21 of September 2012 18:08:13 Marek Vasut wrote:

Quoted 38 lines

Dear Pavel Herrmann,

Quoted 36 lines · On Friday 21 of September 2012 17:39:21 Marek Vasut wrote:

Quoted 34 lines

Dear Pavel Herrmann,

[...]

Quoted 10 lines

Quoted 9 lines

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ). 2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

Quoted 7 lines

I actually did something of this sort, see [4/11], with less touching.

the problem is that while SATA drivers are easy to convert, IDE ones are not. I would actually propose to do a ide_legacy driver (mostly out of the code currently in common/cmd_ide.c), and keep it as the only option until IDE dies completely.

IDE will be around for a LONG time.

You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you did it as
said above, simple CONFIG_DM would suffice as the drivers would be intacts with DM disabled. Note the compiler will opt-out these proxy calls.

Besides, with this approach of yours, you need to enable SATA_LEGACY for every single board now, introducing a lot of churn into the patches and if it's not defined, every board using SATA is broken, right?

Quoted 7 lines

Quoted 3 lines

No, if you dont define CONFIG_DM, you get the old way of interacting with disks. only if you define CONFIG_DM you only need CONFIG_SATA_LEGACY to plug old SATA drivers into DM codepaths

So if you enable DM for a board, you also need to enable this compat layer? My opinion is, that you either enable DM on the board and the board is ready for it or don't enable it.

if you enable DM on a board, you can either use the compat layer and the old driver, or use a ported driver and get rid of the compat layer

Quoted 1 line

Would you need the compat layer at all were you to follow my advice?

Quoted 3 lines

if i understand what you meant, i would build this compat layer into every one of the drivers currently in tree (with some cleanup). in that case, i would not need it

That's correct. You would prepare every driver to be DM-ish and the final deployment of DM would be mechanical. So would be the removal of the non-DM part later on.

Quoted 10 lines

Quoted 10 lines

The whole idea goes deeper, see if you prepended this patchset with such a conversion as above, you'd already have a readily defined structure of blockdev operations in each driver to use in this patchset. This patchset would then really only be the DM stuff. The DM-part addition to the drivers would be mechanical.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

How does that work? It's much cleaner.

Quoted 1 line

Pavel Herrmann

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Quoted 59 lines

Dear Pavel Herrmann,

Quoted 56 lines · On Friday 21 of September 2012 18:08:13 Marek Vasut wrote:

Quoted 39 lines

Dear Pavel Herrmann,

Quoted 37 lines · On Friday 21 of September 2012 17:39:21 Marek Vasut wrote:

Quoted 35 lines

Dear Pavel Herrmann,

[...]

Quoted 11 lines

Quoted 10 lines

Can't the old driver just have a compat section in them? Like I did with serial stuff:

1) rename the internal functions to ${driver}_${function_name} from pure ${function_name} and introduce section which behaves as a wrapper (implement ${function_name} calling ${driver}_${function_name} ). 2) Add your DM goo, implement #ifdef around it so either the compat section or DM section is enabled.

Quoted 7 lines

I actually did something of this sort, see [4/11], with less touching.

the problem is that while SATA drivers are easy to convert, IDE ones are not. I would actually propose to do a ide_legacy driver (mostly out of the code currently in common/cmd_ide.c), and keep it as the only option until IDE dies completely.

IDE will be around for a LONG time.

You introduce that CONFIG_SYS_SATA_LEGACY for no reason, if you did it as
said above, simple CONFIG_DM would suffice as the drivers would be intacts with DM disabled. Note the compiler will opt-out these proxy calls.

Besides, with this approach of yours, you need to enable SATA_LEGACY for every single board now, introducing a lot of churn into the patches and if it's not defined, every board using SATA is broken, right?

Quoted 7 lines

Quoted 3 lines

No, if you dont define CONFIG_DM, you get the old way of interacting with disks. only if you define CONFIG_DM you only need CONFIG_SATA_LEGACY to plug old SATA drivers into DM codepaths

So if you enable DM for a board, you also need to enable this compat layer? My opinion is, that you either enable DM on the board and the board is ready for it or don't enable it.

if you enable DM on a board, you can either use the compat layer and the old driver, or use a ported driver and get rid of the compat layer

Quoted 1 line

Would you need the compat layer at all were you to follow my advice?

if i understand what you meant, i would build this compat layer into every one of the drivers currently in tree (with some cleanup). in that case, i would not need it