[lkml]   [2007]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFD] alternative kobject release wait mechanism
    Hello, Dmitry.

    Dmitry Torokhov wrote:
    > On 4/19/07, Cornelia Huck <> wrote:
    >> On Thu, 19 Apr 2007 09:13:43 -0400,
    >> "Dmitry Torokhov" <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-20 08:03    [W:0.022 / U:305.572 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site