On Thursday, January 19, 2006 5:06 AM, Tim Deegan <> wrote:
> On Wed, Jan 18, 2006 at 01:07:00PM -0500, Jeremy Katz wrote:
>> Sounds reasonable enough, although I'll have to look at it a little
>> closer when I get back from Austin. FWIW, partition table handling
>> in pygrub should work fine (I'm installing to full disk vbds with
>> partition tables regularly)
>
> The partition handling is only enough to find the "active" partition,
> so it doesn't handle extended partitions. That's not a problem for
> pygrub, but would need to be done to have the extraction tool handle
> partitions properly.
>
> Also, it doesn't work if your e2fsprogs are too old to have
> ext2fs_open2() -- again, not really a bug but the failure mode is a
> bit ugly, and the version in the Xen 3 tarball has this problem. Is
> there some way of telling from inside a python script whether the
> pygrub library is going to be able to read partitions or not?
I think that we also need to consider the maintainability aspects of the
two choices. If we want to add new features or support, it would be
best if we only had to modify one code base. For example, adding TPM
support.
It is also conceivable that in the future, a domU's filesystem could be
(partially) encrypted ala MSFT Vista. Coupled with a de-privileged dom0
(or disk driver domain), this might force us into (or require for
maintaining security) a pyGRUB-based solution.
As I understand it, pyGRUB (with Tim's patch) is a superset of
domUloader, at least from a functionality perspective. If so, this
would seem to make it a better choice for a single code base.
Joseph Cihula
(Linux) Software Security Architect
Open Source Technology Center
Intel Corp.
*** These opinions are not necessarily those of my employer ***
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home