On Fri, 2011-09-09 at 16:25 +0200, Arnd Bergmann wrote: > On Friday 09 September 2011, 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. > > > > > > I would generally recommend using new ioctl commands. ioctl numbers > > > are cheap, but complexity in data structures is not, because every > > > user who wants to deal with the data structures has to understand > > > them. Also, changing the ABI is always tricky since you have to > > > provide backward and forwards compatibility with existing kernels > > > and with existing user space. > > > > Hmm, what do we do if ubiblk module is not loaded, and UBI would have > > to return an error (because the block device cannot be created), how > > will UBI know that ubiblk is not there? Any direct call to ubiblk from > > UBI would be a direct dependency and would require ubiblk to be always > > loaded, which is bad. > > No, the idea of this approach is that the main ubi driver creates > a device, which can always succeed. It's just that there won't > be a block device node created, because that is part of what > the ubiblk driver does. > > Compare this to how scsi works: > > A scsi host driver scans the host controller and adds scsi devices > internal to the kernel, each of them have a specific type (disk, > tape, ...). If the scsi disk driver is loaded, it will create > a blockdev for each disk device. It doesn't matter in which order > the drivers are loaded though. > > In case of ubiblk, it's similar, except that there is no way for > the ubi layer to know if some partition should be a block device or > not, so it relies on user space to tell it. There is another difference, though. Disk types are persistent. UBI volumes types are not necessarily persistent: I may create a "just UBI volume", flash something there, may-be re-size, do other things. Then I want to "turn" it into a "ubiblk" volume without destroying it. So I call the corresponding ioctl. And my requirements are: 1) if ubiblk is not loaded, I want to get -ENODEV or something 2) if ubiblk fails, I want to get -ESOMETHING as well. 3) I want to be blocked while ubiblk is creating the block device. Similarly, I may want to ask ubiblk to "release" the volume and turn it to "just a volume" again. So I am not sure the analogy is very close, but thanks a lot for providing it - it makes things clearer. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
