Hi Arnd, 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? > * 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... -- 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
