[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061030104435.623fd057@gondolin.boeblingen.de.ibm.com>
Date: Mon, 30 Oct 2006 10:44:35 +0100
From: Cornelia Huck <cornelia.huck@...ibm.com>
To: Andrew Morton <akpm@...l.org>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>, Pavel Machek <pavel@....cz>,
Greg KH <greg@...ah.com>,
Stephen Hemminger <shemminger@...l.org>,
Matthew Wilcox <matthew@....cx>, Adrian Bunk <bunk@...sta.de>,
Linus Torvalds <torvalds@...l.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [patch] drivers: wait for threaded probes between initcall
levels
On Fri, 27 Oct 2006 16:06:26 -0700,
Andrew Morton <akpm@...l.org> wrote:
> On Fri, 27 Oct 2006 23:59:30 +0100
> Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>
> > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton:
> > > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > > different levels.
> >
> > Thats actually insufficient. We have link ordered init sequences in
> > large numbers of driver subtrees (ATA, watchdog, etc). We'll need
> > several more initcall layers to fix that.
> >
>
> It would be nice to express those dependencies in some clearer and less
> fragile manner than link order. I guess finer-grained initcall levels
> would do that, but it doesn't scale very well.
Would it be sufficient just to make the busses wait until all their
devices are through with their setup? This is what the ccw bus on s390
does:
- Increase counter for device and start device recognition for it
- Continue for next device
- When async device recognition (and probable enablement) is finished,
register device and decrease counter
- ccw bus init function waits till counter has dropped to 0
This has worked fine for us since 2.5. OTOH, s390 doesn't have such a
diverse set as hardware as a PC :)
--
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: cornelia.huck@...ibm.com
-
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