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]
Message-ID: <20080702221600.GB17929@kroah.com>
Date:	Wed, 2 Jul 2008 15:16:00 -0700
From:	Greg KH <greg@...ah.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Andi Kleen <andi@...stfloor.org>, Nathan Lynch <ntl@...ox.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Mackerras <paulus@...ba.org>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: Removing sysdevs? (was: Re: Is sysfs the right place to get
	cache and CPU topology info?)

On Thu, Jul 03, 2008 at 12:08:45AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 2 of July 2008, Greg KH wrote:
> > On Wed, Jul 02, 2008 at 11:41:44PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, 2 of July 2008, Greg KH wrote:
> > > > On Wed, Jul 02, 2008 at 05:14:02PM +0200, Andi Kleen wrote:
> > > > > Nathan Lynch wrote:
> > > > > > Andi Kleen wrote:
> > > > > >> Andrew Morton <akpm@...ux-foundation.org> writes:
> > > > > >>> sysfs is part of the kernel ABI.  We should design our interfaces there
> > > > > >>> as carefully as we design any others.
> > > > > >> The basic problem is that sysfs exports an internal kernel object model
> > > > > >> and these tend to change. To really make it stable would require 
> > > > > >> splitting it into internal and presented interface.
> > > > > > 
> > > > > > True, but... /sys/devices/system/cpu has been there since around 2.6.5
> > > > > > iirc.  A google code search for that path shows plenty of programs
> > > > > > (including hal) that hard-code it.  Exposed object model or not,
> > > > > > changing that path would break lots of software.
> > > > > 
> > > > > Yes it would.
> > > > > 
> > > > > But Greg is making noises of getting rid of sysdevs and it wouldn't
> > > > > surprise me if that ended up being user visible since most object
> > > > > model changes end up being visible.
> > > > 
> > > > I hope to make sysdevs go away in such a manner that the sysfs tree does
> > > > not change at all.  That's my goal, but we still have a long ways to go
> > > > before we can even consider attempting to do this, so don't worry about
> > > > putting things in this location if you feel it is the best fit.
> > > 
> > > Speaking of which, I'm very interested in the removing of sysdevs, since they
> > > don't fit into the new suspend/hibernation framework I'm working on.  Can you
> > > please tell me what the plan is?
> > 
> > The plan is:
> > 	- remaining driver core cleanups to allow for multiple drivers
> > 	  to be bound to individual devices
> > 	- add multiple binding support to the core
> > 	- migrate existing sysdevs to struct device, now that multiple
> > 	  binding is allowed
> 
> Once they've been migrated to struct device, will they reside on specific
> 'system' bus, or will they be platform devices?

I haven't really thought it through more than the above yet, so I don't
know :)

thanks,

greg k-h
--
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