linux-kernel - Re: [PATCH 1/5] initdev:kernel: Asynchronously-discovered device synchronization, v5

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: <Pine.LNX.4.44L0.0905021335150.26241-100000@netrider.rowland.org>
Date:	Sat, 2 May 2009 13:55:45 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	David VomLehn <dvomlehn@...co.com>, <linux-kernel@...r.kernel.org>,
	<akpm@...ux-foundation.org>, <linux-usb@...r.kernel.org>,
	<greg@...ah.com>, <linux-scsi@...r.kernel.org>,
	<netdev@...r.kernel.org>, <arjan@...radead.org>
Subject: Re: [PATCH 1/5] initdev:kernel: Asynchronously-discovered device
 synchronization, v5

On Sat, 2 May 2009, James Bottomley wrote:

> OK, so in your scheme, I get why console devices: they need to be
> present early before we start dumping console output otherwise it can
> get lost.
> 
> However, I don't see the need for either network or block.
> 
> For network, the only early discovery use is net root (which can be done
> fully asynchronously)

Are you referring to the "rootwait" kernel parameter?  Is there a 
reason why this is a boot-time parameter instead of always being set?  
I mean, under what circumstances would you _not_ want to wait until the 
root device is present?

>  or net console (which I think can be supplied a
> raft of information and isn't usually expected to be up by early boot
> because of the TCP stack dependence) neither of which is a compelling
> use case.

Are you sure the real reason it isn't expected to be up isn't the lack
of a mechanism of the type being proposed?

> Block, likewise, is a udev type discovery:  We can specify the root by
> some type of ID and we can wait until that is found, rather than have an
> elaborate system to check when discovery is finished, which is the only
> benefit this code seems to provide.

The real benefit of knowing when discovery is complete is that it tells
you when to give up and stop waiting.  However I have to agree that in
the case of the root device, there really isn't much point in giving
up.

Perhaps with some enterprise systems, it is preferred to have the 
system fail with an explicit error message rather than wait 
indefinitely...

> What I'm getting at is that I don't see the benefit of this in the light
> of Arjan's async boot system, which can also tell us when all discovery
> is complete ... what added benefit am I missing here?

How does Arjan's async boot system tell use when all discovery is
complete?  AFAICS, it only tells you when all its async tasks are
finished.  But device discovery and registration sometimes use other
asynchronous techniques which Arjan's code is unaware of.  Examples:  
the USB khubd thread, the USB mass-storage scanning thread, and the
SCSI async-scanning thread.

Alan Stern

--
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/