linux-kernel - Re: [PATCH RFD] alternative kobject release wait mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Apr 2007 12:35:48 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Tejun Heo" <htejun@...il.com>
Cc:	"Cornelia Huck" <cornelia.huck@...ibm.com>,
	"Alan Stern" <stern@...land.harvard.edu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Greg K-H" <greg@...ah.com>,
	"Rusty Russell" <rusty@...tcorp.com.au>
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism

Hi Tejun,

On 4/20/07, Tejun Heo <htejun@...il.com> wrote:
> Hello, Dmitry.
>
> Dmitry Torokhov wrote:
> > On 4/19/07, Cornelia Huck <cornelia.huck@...ibm.com> wrote:
> >> On Thu, 19 Apr 2007 09:13:43 -0400,
> >> "Dmitry Torokhov" <dmitry.torokhov@...il.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.

I am not saying they are wrong I am just saying that driver core is
not where most work is done. Every subsystem has its own locking rules
and lifetime rules and they are what is important. Whether subsystem
uses embedding or referencing of struct devices is implementation
detail.

What is the goal of driver core? I thought the main goal was to have
an uniform interface for device power management and presentation of
device tree to userspace. It has nothing to do with main purposes of
every individual subsystem - making some set of devices/services work.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/