From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: behavioral change due to new elf code Date: Fri, 09 Feb 2007 14:25:59 +0000 Message-ID: <45CC9287.76E4.0078.0@novell.com> References: <45CC7EC1.76E4.0078.0@novell.com> <45CC7470.4060002@suse.de> <45CC86A5.76E4.0078.0@novell.com> <45CC7E7E.5060607@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45CC7E7E.5060607@suse.de> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Gerd Hoffmann 09.02.07 15:00 >>> >Jan Beulich wrote: >> But wouldn't that change behavior for domU-s then in an undesirable way? > >Why? dom0 and domU should have the same behavior ... I didn't check how the old domU-related tools code behaved here, I just assumed the new code was based more on the old tools code than the hypervisor one, and hence old behavior might have been the one I had just seen. Regardless of that, the function shouldn't return here, but rather continue the loop. >> Even better, I would think, would be to split the note namespace to >> distinguish >> - general required notes >> - general optional notes >> - dom0 required notes > >Point being? I'm not aware of any dom0-required note. And I don't >think splitting into required and optional is useful, especially as this >is arch-dependent ... To e.g. catch notes the presence of which is necessary (i.e. a newer hypervisor will misbehave in its absence), but ignore such that only provide hints in certain directions. At present I also don't know of any dom0 required note, yet if any splitting is done, then all possible (i.e. foreseeable) groups should be allowed for. As you say, the list should also include an arch-specific range. Jan