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. IOW, we need a blocking mechanism to call the upper layer's function (ubiblk) from the lower layer (UBI) which can return an error, and which allows to check if a ubiblk exists at all. Do we have such mechanism? Actually the fact of invoking upper layers from lower makes me worry. And yes, the "bus"<->"devices" model does not look suitable in our case. We have more like hierarchy: ubiblk uses ubi which usese mtd device. David, I am really busy and now, I suggest you to think about this. I'd so far stick to the own ubiblk cdev approach, and would analyse/prototype the approach of using UBI cdev for this. I provided some concerns above. Also, think about race conditions like: 1. Someone -- 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
