Hello, Dmitry. Dmitry Torokhov wrote: > On 4/19/07, Cornelia Huck <[EMAIL PROTECTED]> wrote: >> On Thu, 19 Apr 2007 09:13:43 -0400, >> "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote: >> >> > Because they are managed by 2 different entities. the struct device >> > objects are managed by device core and driver-specific objects are >> > managed by their respective driver. >> >> Not sure if I understand you here. My view of this was always that the >> embedding object was kind of an extended device and that the relevant >> driver/subsystem managed it through the driver core infrastructure. >> > > I am not sure if I agree with this point of view. Driver (or > subsystem) provides an instance of struct device for the rest of the > system to iteract uniformly with (suspend/resume/tree > visualization/etc) i.e. struct device implement an interface for > subsystems. However most of the system use their own mechanisms to > manage their devices. They can rely on the driver core to a certain > degree but driver core is mostly a carries out helper functions, not > the meat.
Many drivers (at least all the SCSI/IDE ones) consider struct device as the base class of the devices those drivers implement. I don't think we can just consider those drivers to be wrong. -- 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/
