On Thursday 25 August 2011, Artem Bityutskiy wrote: > On Wed, 2011-08-24 at 18:23 +0200, Arnd Bergmann wrote: > > That should be fine, yes. I would probably put them into the same > > header file though if they are in the same number space even > > when you use them on distinct devices. > > > > It does feel a little clumsy to have yet another character device > > to manage the block devices though. What do you think about one > > of these alternative approaches: > > > > * When the ubi block device driver gets loaded, create one block > > device per volume and let the user deal with permissions for > > the devices instead of having to first create them as well. > > I think this wasteful. Why should I have block devices which I do not > need? If I have 4 UBI volumes, and need only one ubiblk, why should I > waste my resources for 3 more of them (e.g., I do not want to waste > memory for struct inode for each sysfs entry which these useless block > devices will add). Also, will this mean 3 more block devices registered? > > I think it is much uglier to have 3 "dummy" block devices and confuse > users than have one nice control character device. For the sake of not > having a separate control chardev? The cost of a block device node in the kernel is rather low. Nowadays, sysfs does not even permanently use inodes for entries, it has a much more compact internal representation IIRC. The main advantage of this approach is not having to set up the block device at all, it would just be there, which e.g. makes it possible to put a root file system on it or do something else without requiring a user space tool to issue an ioctl. Evidently you can do everything you need even with that user space tool, but IMHO the complexity of doing that is way bigger than just creating the block devices right away. > > * 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. > > This sounds better IMHO, but I am still not sure that adding another > dummy bus and exposing it in sysfs and more complexity in the ubiblk > code is more elegant and less wasteful than just creating a separate > chardev... It's not a dummy bus, in this approach it would be a the bus that gets used by all ubiblk devices, which is a very common concept by itself. It's more like the classic understanding of a 'device class' that Greg wants to see get replaced by bus_types in the kernel. Arnd -- 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
