From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [Fwd: [Xen-users] two serial port in HVM DomU patch] Date: Sun, 6 Jan 2008 22:42:12 +0000 Message-ID: <20080106224212.GC5345@redhat.com> References: <4778DCD2.2030300@netz-haut.de> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Stephan Seitz , XEN Devel - listmembers List-Id: xen-devel@lists.xenproject.org On Sun, Jan 06, 2008 at 10:43:23PM +0000, Keir Fraser wrote: > I'd advocate a dm_args domain config option, which would be a string of qemu > command-line arguments which would be dumbly passed straight through to > qemu-dm without any further processing by xend. > > Then you could just do 'dm_args = "serial=/dev/ttyS0 serial=/dev/ttyS1"' and > not need any changes to qemu source code at all. And this would also let you > get at any other underlying features of qemu too. Much nicer. I think that's a bad idea as any info in this generic 'dm_args' is now lost to the formal API data model. eg If a management app wants to talk to XenD and determine how / if the serial port is configured, it now has to look at both the formally specified 'serial' param, and also parse the command line args in 'dm_args'. Sure it means we have to write less code in XenD, but it means that all users talking to XenD have much more work todo. I don't really see that as a net win. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|