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]

Message-ID: <462C54D5.6000101@gmail.com>
Date:	Mon, 23 Apr 2007 15:40:21 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...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

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