[lkml]   [2009]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 0/3] sysfs: allow suicide
    * Eric W. Biederman <>:
    > Alex Chiang <> writes:
    > > * Eric W. Biederman <>:
    > >>
    > >> Interesting.
    > >>
    > >> Fixing a read/writer deadlock by allowing the writers to nest
    > >> inside the readers.
    > >>
    > >> My first impression is that it is too clever.
    > >
    > > Clever points go to Tejun. All I did was refresh the series
    > > slightly. :)
    > >
    > >> Furthermore I think this is walking around the edges of a more
    > >> general problem. How should we serial hotplug and hotunplug
    > >> in general. In what context should remove methods run in.
    > >>
    > >> My impression is that we have a huge hole in our infrastructure
    > >> for hotplug drivers. Problems like how do we get a user space
    > >> context for the code to run in and how do we handle
    > >> multiple hotplug actions for overlapping device trees from
    > >> stomping on each other.
    > >>
    > >> My hypothesis is once we solve this for the general case of
    > >> device hotplug and removal we won't need special support from
    > >> sysfs. At least not in the suicidal way.
    > >
    > > I agree that we have problems in our infrastructure, especially,
    > > as you point out, overlapping device trees, etc.
    > >
    > > I see your point about adding extra cruft into sysfs to work
    > > around a special case while leaving the hard problem unsolved.
    > >
    > > Perhaps the status quo is better. I do think that getting
    > > suicidal sysfs attributes off the global workqueue is a band-aid
    > > that actually helps, vs. the proposed patches here which are
    > > questionable in nature.
    > Sounds like it. I'm not trying to shoot this down, rather
    > I'm trying to figure out how to solve this cleanly, as I am slowly
    > trying to sort out the pci hotplug and unplug issues.

    Please do keep me informed on any progress you make or thoughts
    you have here.

    > I'm not certain how general we can be. pci layer, device layer or kobject
    > layer, but I think it makes sense to have a dedicated work queue to use
    > when devices are removed. As every hotplug driver currently has to
    > invent one. The fake hotplug code is very normal in this respect.
    > If we can get the work queue creation and the calling of remove put
    > into the generic pci layer, we should be able to simply all of the
    > hotplug controller drivers.

    Hm, that is a good idea.

    Simplifying all the various hotplug drivers is on my TODO list,
    but it's a long and tricky process. I agree though, there is no
    reason why they should all be as complicated as they are.

    > I'm not seeing a patch from you where you are using a separate
    > workqueue. Am I missing something?

    But I suspect that is not the workqueue you are looking for. ;)

    > But if we can place that workqueue in say the pci layer I think
    > it would be just a little re factoring and not a lot more code.

    The PCI layer doesn't need a workqueue to remove devices, not on
    its own behalf.

    You are talking about providing something for the benefit of all
    the hotplug drivers, right?



     \ /
      Last update: 2009-03-26 02:29    [W:0.024 / U:8.196 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site