Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: Removing sysdevs? (was: Re: Is sysfs the right place to get cache and CPU topology info?) | Date | Thu, 3 Jul 2008 00:08:45 +0200 |
| |
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@linux-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?
> - delete sysdev structure > - profit! > > It's that first step that is taking a while, the last big changes will > be going into 2.6.27 to help accomplish this, after that merge happens > for 2.6.27-rc1 I'll be working on the remaining steps.
Sounds good, please let me know if you need help.
Thanks, Rafael
| |