Messages in this thread |  | | Date | Fri, 20 Apr 2007 14:59:21 +0900 | | From | Tejun Heo <> | | Subject | Re: [PATCH RFD] alternative kobject release wait mechanism |
| |
Hello, Dmitry.
Dmitry Torokhov wrote: > On 4/19/07, Cornelia Huck <cornelia.huck@de.ibm.com> wrote: >> On Thu, 19 Apr 2007 09:13:43 -0400, >> "Dmitry Torokhov" <dmitry.torokhov@gmail.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |