[arch-projects] [PATCH] init_functions: rework `default_mount_handler` -- assume less/succeed more

[C Anthony Risinger]

On Thu, Nov 17, 2011 at 12:25 PM, Thomas Bächler <thomas at archlinux.org> wrote:
>
> The whole major/minor comment confuses people. Simply state that the
> root device does not exist and/or could not be created.

sure sure, can do.

On Thu, Nov 17, 2011 at 12:45 PM, Dave Reisner <d at falconindy.com> wrote:
> On Thu, Nov 17, 2011 at 12:01:52PM -0600, C Anthony Risinger wrote:
>
> root= is extremely *non*-arbitrary. It always exists, and it's 1 of
> three things:
>
> - a filesystem path to a block device (e.g. /dev/sdxy or
>  /dev/disk/by-....)
> - a tag with a value (LABEL=mysweetdisk)
> - a hex encoded major/minor device number (e.g. fe01)
>
> That's all it can ever be in the current codebase.

but this is the crux of what i meant by `is opaque` -- by assuming the
root= can never be anything but the above, you have limited it's
general applicability.  all it needs to do is attempt running "some
command that makes /new_root available", it doesn't need to care about
anything else because it's essentially a high level interface for the
user.  by moving the blockdev check somewhere else, you could reuse
`default_mount_handler` as general "UI" logic for any mount hook, be
nfs/9p/.../.../etc

> And that said, I broke out resolution of the root= parameter to its own
> function so that the mount handler never needs to see it as anything
> but a filesystem path to a block device.

... and that is a great change, taking it 95%, this is just the last %5.

> There seems to be a much simpler solution to all this, which is sort of
> in line with your idea. Don't assume that mount will fail. Just try it,
> and let it fail. Only then, when it does, check to see if its a block
> device and complain, e.g.
>
> http://code.falconindy.com/cgit/mkinitcpio.git/commit/?h=throwaway

that solves my immediate need, yes.  i figured i would improve the
interface while i was there, since by default, no details are provided
about the fail, and it's lees than obvious what the next step
could/should be (esp. for someone not expecting the fail, or seeing it
for the first time).

> Not going to comment on the rest of this.

excellente!  i presume that's roughly analogous to "i like my
opponent, i think he's a good man, but quite frankly" ...

... "i-agree-with-everything-he-just-said" ... ;-)

tbc

-- 

C Anthony