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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 30 Mar 2007 12:58:21 -0500
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Tejun Heo <htejun@...il.com>, gregkh@...e.de, hugh@...itas.com,
	cornelia.huck@...ibm.com, oneukum@...e.de, maneesh@...ibm.com,
	rpurdie@...ys.net, Jeff Garzik <jgarzik@...ox.com>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	SCSI Mailing List <linux-scsi@...r.kernel.org>
Subject: Re: [RFD driver-core] Lifetime problems of the current driver model

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


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ