On Mon, Apr 23, 2007 at 03:40:21PM +0900, Tejun Heo wrote: > Hello, Dmitry. > > Dmitry Torokhov wrote: > > Isn't think a good thing? By decoupling the 2 layers we insulate them > > from changes in each other. This allows bug subsystems to concentrate > > on topics that important to them instead of worying about refcounting > > objects that are not directly interesting for the subsystem in > > question. > > I think the best thing would be make struct device's lifetime rules > simple enough such that it doesn't really matter to driver subsystems > and drivers can just do what they wanna do.
I agree. > Also, separate struct device from the actual implementation has problem > in that struct device is widely used to refer to the device by many > layers drivers register devices to. Basically, you'll have to implement > immediate-disconnect between struct device and the actual > implementation. So, it just shifts the problem from struct device to > the place between struct device and actual implementation and I think > struct device itself is better place to deal with that than somewhere > inbetween it and driver private data. I also agree. > > Now for smaller subsystems it may make sense to embed stuct devices > > into subsystem objects and manage it all together. In fact input > > system does this but I think it is much simlpier than SCSI or IDE. > > Well, both SCSI and IDE heavily depend on struct device acting as 'base > class'. It's all over the place and almost a basic assumption about the > driver model. And that's how it should be. And your sysfs patches now make it a lot easier than before, and I can't thank you enough for doing that work. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
