On Wed, Mar 01, 2006 at 11:53:08PM -0500, Jeremy Katz wrote:
> > 3) bootloaders are forced to return configuration params like 'args', since
> > the code assumes it knows all with regards to image.py
>
> A boot loader _does_ need to pass back everything regarding an image,
> though. All of kernel, initrd and arguments can and should be
> accessible/modifiable by the boot loader.
Yes. However, it is not right to *demand* that the bootloader provide
all of these. This is the case with the current interface:
if vals.bootloader:
config.append(['bootloader', vals.bootloader])
config_image = run_bootloader(vals)
> > In addition, the common case of "just get these files off the filesystem at
> > this device" is not, IMO, well-covered by pygrub, the only bootloader
> > shipped
> > so far:
> >
> > 1) Filesystem support requires a C/Python interface which contains a lot of
> > glue code, typically interfacing a C library to pygrub's internal API
>
> Based on a couple of discussions I had in Austin, I think the right
> thing to do here is probably to get to where we can use the grub2
> filesystem modules. It shouldn't be that bad to do, I've just been
> caught up with some more mundane things instead of having time to get
> around to it yet.
Well, that would certainly be good. But see my comments regarding the
general utility of readfs.
> > 2) Filesystem support needs to be delivered into the correct python
> > directory, and carefully match the exact internal API used by pygrub
>
> It's hardly that complicated of an API. Actually, it's probably too
> simple more than anything
Simplicity is not the issue, stability is. This sounds like you want to
change it already.
> > 3) There are possibly licensing inflexibilities with the fs-specific python
> > modules. Not really a big problem with the standard open OS's
> > filesystems,
> > but I can easily imagine this being a problem with vendor filesystems, or
> > other operating systems.
>
> I think that encouraging closed source implementations here is a bad
> idea for allowing interoperability between guests.
I'm not even necessarily talking about closed source, and I do not want
to get into a fruitless "discussion" about licensing to be honest. The
Xen sources have gone to a significant amount of effort to allow non-GPL
compatible guests already. I do not accept that it is the intent of the
Xen project to require all platform-provided guest domain code to be
GPLed.
> Why invent yet another config file format that everything that anyone
> would want to use within a guest has to be able to parse instead? Sure,
> the grub syntax has its warts, but it works well enough. And creating
> something else involves a completely separate knowledge set for users
> inside of a guest vs on physical machines.
Until such a time that grub is ported to Xen and all domU's are updated,
it does not make sense to use a config file of an unrelated program to
hold this data. And when that does happen, pygrub can be deleted as
well.
> > Taking a lead from the disk configuration, the 'kernel' and 'ramdisk'
> > options
> > are extended to the format:
>
> *shrug* I continue to think that specifying kernel and ramdisk from
> dom0 is non-interesting :)
That indeed may be your opinion, but I am not seeing a universal use of
pygrub. But that isn't even the issue here: this general scheme allows
anything to be passed to a custom bootloader, not necessarily specify
paths to the kernel/ramdisk.
> > The Xen python code parses the 'kernel' value into 'method' and 'params',
> > then
> > searches for a bootloader handler matching 'method' as follows:
> >
> > /usr/lib/xen/boot/bootload-<method>
> > <auxbinpath>/bootload-<method>
> > /etc/xen/scripts/bootload-<method>
>
> Since you have to specify the same method for kernel and ramdisk, this
> is pretty much the same as the current bootloader config option.
Except that pygrub isn't assumed which both requires the pygrub-specific
"bootentry" and ignores kernel/ramdisk choices.
> > When found, the bootloader is invoked as follows:
> >
> > -b <bootdisk> -k <kernel's method-param> [-r <ramdisk's method-param>]
> > \
> > -d <disk1> [ -d <disk2> ... ]
>
> What params do you see making sense here?
For grub method, the boot entry, and later, the kernel if wanted. For
root method, kernel/ramdisk path. For XXX bootloader, some
method-specific parameters. That's the point, it doesn't tie all domU's
into some Fedora-specific approach.
regards,
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home