From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbXC3R6p (ORCPT ); Fri, 30 Mar 2007 13:58:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752068AbXC3R6p (ORCPT ); Fri, 30 Mar 2007 13:58:45 -0400 Received: from hancock.steeleye.com ([71.30.118.248]:58248 "EHLO hancock.sc.steeleye.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752008AbXC3R6o (ORCPT ); Fri, 30 Mar 2007 13:58:44 -0400 Subject: Re: [RFD driver-core] Lifetime problems of the current driver model From: James Bottomley To: Dmitry Torokhov Cc: Tejun Heo , gregkh@suse.de, hugh@veritas.com, cornelia.huck@de.ibm.com, oneukum@suse.de, maneesh@in.ibm.com, rpurdie@rpsys.net, Jeff Garzik , lkml , "linux-ide@vger.kernel.org" , SCSI Mailing List In-Reply-To: References: <460CDBA6.5030608@gmail.com> <1175257751.3760.19.camel@mulgrave.il.steeleye.com> Content-Type: text/plain Date: Fri, 30 Mar 2007 12:58:21 -0500 Message-Id: <1175277501.3760.32.camel@mulgrave.il.steeleye.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2007-03-30 at 09:15 -0400, Dmitry Torokhov wrote: > If you want to manage lifetime rules independently you might want to > not embed struct device into you subsystems objects but attach them > via pointers and use device_create(). Now that we orphan sysfs access > upon unregistering device this will severe all ties from driver core > to your system once you start teardown of a device and you should be > in clear. But that wouldn't really help ... all objects have lifetimes. What Tejun is pointing out is that we have two different lifetime requirements: driver internal (and subsystem) objects and sysfs objects ... we still need something embedded in the driver objects, so it may as well be struct device ... trying to manage struct device outside of the driver objects would turn into another nasty refcounting problem. The struct device is usually the generic abstraction of the specific structure it's embedded in, so I think it really does make sense to keep these pieces together. > However there are simpler subsystems (input, serio, etc.) where there > is only one core module which provides services to device drivers and > handles registration and deregistration. For such substustems it makes > sense to embed struct devices and manage lifetime for all components > at once. James