On Fri, 2011-09-09 at 14:53 +0300, Artem Bityutskiy wrote: > 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 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. Anyway, I suggest the following algorithm: 1. Stick with the own cdev approach - the driver becomes very simple in this case - we review it. 2. Once it is ready, or in parallel, you can play with the second approach and if you find it solid/nice, you can then provide a new version and/or the delta. The idea is that on step 1 we review/deal with other things, without being blocked by the ioctl stuff. -- 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