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. 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. > 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. -- tejun - 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/
