lkml.org 
[lkml]   [2008]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Removing sysdevs? (was: Re: Is sysfs the right place to get cache and CPU topology info?)
    Date
    On Thursday, 3 of July 2008, Greg KH wrote:
    > 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@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?
    >
    > I haven't really thought it through more than the above yet, so I don't
    > know :)

    This is quite important, though, because the device objects that sysdevs will
    be replaced with should provide suspend/hibernation callbacks to be run with
    interrupts disabled, while for some of them it may also be convenient to
    provide "normal" suspend/hibernation callbacks to be run with interrupts
    enabled.

    For this reason their bus type will have to be quite similar to the platform bus
    type.

    Thanks,
    Rafael


    \
     
     \ /
      Last update: 2008-07-03 01:09    [W:0.023 / U:3.488 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site