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

[Dave Reisner]

On Thu, Nov 17, 2011 at 12:01:52PM -0600, C Anthony Risinger wrote:
> On Thu, Nov 17, 2011 at 3:24 AM, Thomas Bächler <thomas at archlinux.org> wrote:
> > Am 17.11.2011 07:20, schrieb C Anthony Risinger:
> >> +    if ! mount ${opts} "$root" "$1"; then
> >> +        if [ ! -b "$root" ]; then
> >> +            err "Unable to determine major/minor number of root device '$root'."
> >> +        fi
> >
> > This error message no longer makes sense. Replace it by something
> > understandable.
> 
> sure, how about (as a msg instead of err):
> 
> "Is root device a /dev/<blockdev>? Unable to determine it's major/minor number."
> 
> ... or...
> 
> "Root device does not exist -- not a block device, or unable to
> locate/determine it's major/minor number."
> 
> ... something like that?
> 
> On Thu, Nov 17, 2011 at 8:11 AM, Dave Reisner <d at falconindy.com> wrote:
> > On Thu, Nov 17, 2011 at 12:20:54AM -0600, C Anthony Risinger wrote:
> >> mostly shuffling, save:
> >>
> >> 1) immediate mount attempt: assume hooks have allowed for this
> >> $root is opaque, attempts to dechiper it's meaning are out of scope.
> >
> > I have no idea what this means.
> 
> i meant that to the handler, $root is an arbitrary string (ie, "black
> box" of sorts) -- it has no way to really understand what it could
> mean.  IMO, the `handler` should only be concerned with the high-level
> flow, not attempt to make concrete decisions.

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

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

Not going to comment on the rest of this.

d

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20111117/6eb471a6/attachment.asc>