| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: domUloader kernel command line arguments?
On Fri, Mar 10, 2006 at 11:41:40PM -0000, Ian Pratt wrote:
> I'm not a fan of pygrub as that requires very new versions of the
> filesystem libraries (to support "open2" and hence patition table
> offsets).
>
> Perhaps we should be considering having both in tree? I've somewhat lost
> track of where we are in the discussion as regards to support for Sun's
> UFS. Could someone please generate a summary?
I sent a proposal regarding the configuration format for bootloaders.
Jeremy had some issues that centered around:
o he didn't like the format I suggested. I proposed one closer to that
currently provided, but haven't had a response to that yet
o he believes that the current "supply a Python module" interface to
file systems is OK and that all domu's are expected to provide GPLed
sources (not necessarily a huge problem for us but I do worry about
other situations in the future).
o he pointed out that for Fedora/RHEL, the current solution is
sufficient.
o he appeared to be against the notion of enabling other boot loaders
beyond the current (limited) interface
Apologies if I've mis-represented anything here; Jeremy's posts are not
available in the mail archives.
There was general agreement that a solution that defers all
configuration to the domu such as grub xen support was the best
long-term option. I do not think that this affects the current
discussion, however.
I believe the biggest issue that needs to be resolved is where the
filesystem-reading code belongs. I've been advocating that the relevant
dom0 systems provide a 'readfs' binary that defer to particular
implementations for each file system. This would help take the
maintenance burden off the Xen project itself, and centralise all FS
handling in one sensible place. (In particular, such a project could
easily ship with its own ext2fs library so the open2 support issue goes
away for now). So far this idea does not seem popular, but I've not
received any details as to why. I believe that an opaque interface
provided by a command line binary is safer in the mid/long-term than
requiring a Python module to be delivered, mainly due to the fact that
Python is still changing incompatibly, and the stability of the internal
pygrub API is under doubt (Jeremy has mentioned he wants to make changes
already).
My changes should also work well with Kurt's loader which Novell are
using. As a by-product it resolves some of the problems with the
bootloader interface that domUloader has.
I hope I've not missed anything important here; corrections are welcome.
regards,
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home