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: <1241272876.3639.27.camel@mulgrave.int.hansenpartnership.com>
Date:	Sat, 02 May 2009 09:01:16 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	David VomLehn <dvomlehn@...co.com>
Cc:	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 Fri, 2009-05-01 at 19:25 -0700, David VomLehn wrote:
> +Init Device Discovery Synchronization
> +=====================================
> +Init devices are those devices that must be used or configured before
> +starting up the /bin/init process.  They may be explicitly specified as
> +kernel command line parameters, such as console=ttyUSB0,115200, or
> +implicitly specified, such as ip=dhcp.
> +
> +Earlier versions of the Linux kernel used a single-threaded approach to
> +boot initialization. This took a number of seconds, which meant that
> +devices were generally set up before being used or configured. Modern
> +kernels use a multithreaded approach, which requires synchronization between
> +code that probes and initializes init devices, and code that uses and
> +configures them.  Support of fine-grained boot concurrency requires
> +distinguishing between types of init devices, so that devices can be used as
> +soon as they are initialized.
> +
> +There are several types of init devices:
> +-	consoles
> +-	network devices
> +-	block devices

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) 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.

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.

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?

James

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