From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 0/3] domUloader Date: Wed, 18 Jan 2006 22:31:22 -0600 Message-ID: <43CF161A.3060309@us.ibm.com> References: <20060116234330.GC17087@tpkurt.wlan.garloff.de> <43CCDA6E.5040608@us.ibm.com> <1137607564.22846.13.camel@bree.local.net> <20060118232122.GZ16322@tpkurt.wlan.garloff.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060118232122.GZ16322@tpkurt.wlan.garloff.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kurt Garloff Cc: Jeremy Katz , Xen development list List-Id: xen-devel@lists.xenproject.org On a side note, one thing we all have to think about is how a boot loader would work with something like a virtual framebuffer. It may be time to start thinking about writing a first class domU bootloader. Something that just sets up a page table that maps the pfns linearly and enough XenBus to read from a virtual disk. We can reuse code from grub for filesystem parsing (or even write it from scratch--it's not that hard to just read from a filesystem). We could also use mini-OS as a base. Regards, Anthony Liguori Kurt Garloff wrote: >Hi Jeremy, > >On Wed, Jan 18, 2006 at 01:06:04PM -0500, Jeremy Katz wrote: > > >>The other concern with mounting is that there have been some cases where >>changes to filesystems have broken reading new filesystems with older >>kernels. It's a lot easier to get the library that supports more (and >>less has to be supported, so you're less likely to need to make changes) >>than to upgrade your kernel for dom0 >> >> > >I tend to disagree. >As the dom0 kernel drives the hardware and hardware drivers seems >to be the more prominent reason for moving to new kernel versions, >I would assume the dom0 kernel to be updated more likely than the >domU kernels. >And actually, filesystem forward compatibility is not that bad. > >I'm not saying this can't be an issue, but I suspect it won't be >for most people. > >Cheers, > >