Re: partition store type?

[Roland McGrath]

> Well, the user would have to determine the block list notation of a
> partition manually. Note that gnumach is not recognized by GRUB
> specifically, so GRUB has no opportunity to pass any gnumach-specific
> argument automatically. Thus, if Hurd requires that the user adds
> information on a root partition to the command "kernel", the user
> needs to run a command to calculate the block list of a partition and
> then to paste it. That sounds unreasonably non-user-friendly to me.

Back in the mailing list archives someplace can be found where I've
suggested this same tedious procedure for booting the hurd from a
filesystem image inside a file.

> So I think it is a much better way to have a library to interpret
> partitions than to have GRUB to do the dirty work.

I think we are going to take that approach on the Hurd anyway for unrelated
reasons.  But rather than giving up on the approach, these two potential
uses suggest to me that it would useful to have some facility in GRUB that
could be made to fill the need.

I have always thought about this sort of thing in the context of GRUB doing
boot script processing.  My thinking is to have GRUB read boot scripts, the
basic functionality being to discard # comments and blank lines, and for
each file-name line load a multiboot module from the filesystem, using the
entire line as the module string.  (We then have the kernel interpret the
the $ magic as serverboot does now.)  It makes sense to have GRUB do some
form of expansion on these strings, to substitute things like the root
device and the boot command line.  In this context, it makes sense to add
various kinds of GRUB metasyntax in these scripts, such as ways to set some
GRUB metavariable to the blocklist for some partition or file.