Re: [PATCHv3] UBI: new module ubiblk: block layer on top of UBI

David Wagner
2011-09-09T14:37:42Z

On 09/09/2011 01:53 PM, Artem Bityutskiy wrote:
> On Thu, 2011-09-08 at 17:26 +0200, Arnd Bergmann wrote:
>> On Tuesday 06 September 2011, Artem Bityutskiy wrote:
>>> Not sure about the bus approach - David, could you take a look at it
>>> please? If we can handle errors there - then we could indeed re-use the
>>> UBI control device. We could even re-use the ioctl data structures for
>>> UBI volumes creation/removal - we have plenty of space there reserved
>>> for future extensions.
>>

@Arnd:
> * Use the existing UBI control device for the block devices as
> well and just add two more ioctls to create the devices.
> You can add a logical bus_type for this so that the ubi block
> driver gets automatically loaded matched with the device when
> one is created using the control device.

I certainly miss some background, I'm not sure I understand how this
works: bus_type seems suitable for pluggable devices that possess a
device ID which matches against a driver that will then get loaded. But
ubiblk devices are created by ubiblk.
So, are you suggesting to move ubiblk_create() to UBI and add a
MODULE_ALIAS to ubiblk (actually, I don't know what it would contain) ?

(I just saw that you sent an email while I was writing this one ;
however, I still understand. I'll try and read how scsi does that).

@Artem:
> Sorry, I wonted to talk about situations when someone opens an ubiblk
> device while the underlying UBI volume is being removed, but then though
> this is trivial and forgot to erase the last sentence.

Ah, yes, I guess we need to hold a vol_lock in ubiblk_remove() ?

> Anyway, I suggest the following algorithm:
>
> 1. Stick with the own cdev approach - the driver becomes very simple
> in this case - we review it.

This is the way it's implemented in v4, right ?

BTW, those are the changes made so far since v4:
* Add missing headers (they are included by other headers but it seems
to be good practice not to rely on that).

* Remove an macro rendered useless with the linked lists

* correct some formatting in kerneldoc comments

* introduce refcounting to avoid multiple opens or closing a UBI
volume while still in use

* make checkpatch happy about assignation inside a condition

* use DEFINE_MUTEX for devlist_lock

Best Regards,
David

--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.