CHROMIUM: make dm= boot path wait for devices

CHROMIUM: make dm= boot path wait for devices

Prior to configuring mapped drives, we attempted to pre-resolve devices
out of the table configurations using the same logic as the other init
code.  However, like md, this may occur before devices are available.

This means that dm booting to a USB device will likely fail.  This
change adds root_wait-style code during device name resolution.  If the
device is not present, then the system will be blocked anyway.  If it
resolves after some period, then we can proceed. If the device resolves
immediately, then we never use this code.

It's worth noting that this will NOT wait for major:minor specified
devices.  I think that's probably okay, but it could be added if it makes
sense.  (forking this off to a separate function which rewalks looking for
' /dev/' or  ' digit*:digit* ')

Signed-off-by: Will Drewry <wad@chromium.org>;

TEST=built a kernel and booted a verified rootfs off of usb with it
BUG=chromium-os:327
Change-Id: I350b4deceeeff3c499b4c3e00e4d7ae0645f8b16

[Olof Johansson, 2010-07-22 01:28:23]

Techically nothing forces you to have your device nodes in /dev/, so basing the
delay decision on that seems a little odd. But it's common practice, so I guess
it's ok. It would probably be overkill to add a new variable "dmwait" or
similar, but I could see some arguing that way.

Besides the seemingly unrelated variable introduction, I'm otherwise ok with
this. I do suggest floating this on the list together with the other patch
though.

http://codereview.chromium.org/3059004/diff/1/2
File init/do_mounts_dm.c (right):

http://codereview.chromium.org/3059004/diff/1/2#newcode368
init/do_mounts_dm.c:368: int failed = 0;
This looks unrelated?

[Will Drewry, 2010-07-22 01:58:48]

On 2010/07/22 01:28:23, Olof Johansson wrote:
> Techically nothing forces you to have your device nodes in /dev/, so basing
the
> delay decision on that seems a little odd. But it's common practice, so I
guess

Ah, before you have a rootfs, /dev/ seems to be the default way to specify
device nodes - esp with devtmpfs.  The init code then strips it off and tries to
figure out who it belongs to.  I followed this practice, but the only thing I
don't wait on are major:minor specifications.

I was thinking that specifying the major:minor is often special case for root=
(nfs) and would be unlikely - at least for needing dm_wait-style support. Also
it would be more work ;)

Does that seem sane?

> it's ok. It would probably be overkill to add a new variable "dmwait" or
> similar, but I could see some arguing that way.

Yup - it doesn't seem like it'd be a big deal to add, but since boot should
block anyway I didn't think it was worth it.

> Besides the seemingly unrelated variable introduction, I'm otherwise ok with
> this. 

I fixed the variable introduction!  Soo is that a LGTM? :)

>I do suggest floating this on the list together with the other patch
> though.

I can repost the series of patches again.  Do you mind if I do that after and
clean up here or would you prefer it before?

thanks!
will

http://codereview.chromium.org/3059004/diff/1/2
File init/do_mounts_dm.c (right):

http://codereview.chromium.org/3059004/diff/1/2#newcode368
init/do_mounts_dm.c:368: int failed = 0;
On 2010/07/22 01:28:23, Olof Johansson wrote:
> This looks unrelated?

Done.

[Olof Johansson, 2010-07-22 15:10:05]

On 2010/07/22 01:58:48, Will Drewry wrote:
> On 2010/07/22 01:28:23, Olof Johansson wrote:
> > Techically nothing forces you to have your device nodes in /dev/, so basing
> the
> > delay decision on that seems a little odd. But it's common practice, so I
> guess
> 
> Ah, before you have a rootfs, /dev/ seems to be the default way to specify
> device nodes - esp with devtmpfs.  The init code then strips it off and tries
to
> figure out who it belongs to.  I followed this practice, but the only thing I
> don't wait on are major:minor specifications.
>
> I was thinking that specifying the major:minor is often special case for root=
> (nfs) and would be unlikely - at least for needing dm_wait-style support. Also
> it would be more work ;)
> 
> Does that seem sane?


Yeah, that's reasonable to me. I was just trying to predict what some cranky
LKML-poster might be saying. :) I'm ok with the current solution.

> > it's ok. It would probably be overkill to add a new variable "dmwait" or
> > similar, but I could see some arguing that way.
> 
> Yup - it doesn't seem like it'd be a big deal to add, but since boot should
> block anyway I didn't think it was worth it.
> 
> > Besides the seemingly unrelated variable introduction, I'm otherwise ok with
> > this. 
> 
> I fixed the variable introduction!  Soo is that a LGTM? :)
> 
> >I do suggest floating this on the list together with the other patch
> > though.
> 
> I can repost the series of patches again.  Do you mind if I do that after and
> clean up here or would you prefer it before?

You can do it later. My main worry would be if there is strong arguments to add
a dmwait, since we would then need to do it on our bootargs as well when we move
over to the new behavior. It should be manageable if it comes down to it though.


Anyway, that was all a verbose way of saying:

LGTM.


-Olof