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: <4628EFB2.9070709@gmail.com>
Date:	Sat, 21 Apr 2007 01:52:02 +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:
>> 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.

I think we're running in circle here.

1. The driver's lifetime rules matters but currently the driver model
imposes reference counted model to each struct device.

2. You can decouple struct device completely from actual driver
implementation.

I agree with you that #2 is possible but just don't think it's the right
thing to do.  By making struct device independent from driver
implementation doesn't help solving lifetime problems in drivers.  It
just insulates driver model from those.

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