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: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ