[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] - make qemu serial summagraphics settings a bitmore fluid


  • To: "Ben Thomas" <bthomas@xxxxxxxxxxxxxxx>
  • From: "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
  • Date: Thu, 18 May 2006 14:42:42 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 18 May 2006 14:44:09 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZ6wkpZhXkbW09TQeOQLQ1L1i9+GwAAEMXw
  • Thread-topic: [Xen-devel] [PATCH] - make qemu serial summagraphics settings a bitmore fluid

Ben-

That explains how it, you're explictly setting the serial name from the
command line.  For the case of the Summa driver I think it's redundant
to require the `-serial' flag.  Right now the driver is, by definition,
a serial device and, therefore, if you specify a Summa port you are
implicitly saying you want to reserve that serial resouce.
Note that the serial console on port 0 is also implicitly specified,
that was the model I was following.

I would prefer to see it that where you process the `-summ' flag you set
the appropriate serial device name to "nul" at the same time, I think
that's easiest for the user.

There's no need to be able to specify more than one serial port as a
Summa device, it doesn't make sense and the rest of the code isn't set
up to handle that any way.  I see it that there are only two options, no
Summa or Summa on port n.  That's why I was saying you don't need an
array, just an integer.  The integer holds -1 to indicate no Summa at
all and the serial port number otherwise.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@xxxxxxxxx
Ph: (303)440-1368 

>-----Original Message-----
>From: Ben Thomas [mailto:bthomas@xxxxxxxxxxxxxxx] 
>Sent: Thursday, May 18, 2006 3:30 PM
>To: Dugger, Donald D
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] [PATCH] - make qemu serial 
>summagraphics settings a bitmore fluid
>
>Hi Don,
>
>I have this code running in another tree, so let me try to go
>through these.  It's quite possible that qemu has outsmarted
>me in this configuration.
>
>Dugger, Donald D wrote:
>> Ben-
>> 
>> I like the idea but I don't understand how this patch can work:
>> 
>> 1)  You never put a name into `serial_devices[]' for the summa port.
>> The loop in `main' that initializes the serial devices only calls
>> `qemu_chr_open' if there's a string name in 
>`serial_devices'.  How did
>> you get this to work?
>
>I use -serial in the qemu command line.  For instance, I generally
>use something like -serial pty -serial pty -serial null -serial pty,
>which is asking for COM1, COM2 and COM4 assignments to a pty.  
>The model
>is that you ask for a serial line, and also optionally 
>indicate that you
>want it to be summagraphics.
>
>For instance, here's a command line that I just generated/used.
>It requests multiple serial lines. none of which are summagraphic.
>
>/bin/qemu-dm -d 7 -m 256 -monitor pty -serial pty -serial pty 
>-serial pty
>   -serial pty -vnc -vncconnect 10.1.2.26 -k en-us -timeoffset -1800
>   -vcpus 1 -macaddr 00:0f:4b:11:01:89 -bridge nexbr1 -hda /dev/dm-4
>   -domain-name "Fedora Core 4 - 32 Bit"
>
>> 2)  Minor point, I don't see the need for the `serial_summa' array, a
>> simple integer that is initialized to -1 would accomplish the same
>> thing.  (I have this thing about wasting memory :-)
>
>I use the array so that I know which of the COMn ports are actually
>using the Summagraphic protocols.  A bit array would work as well,
>I suppose.
>
>I chose to allow any/all/none of the ports to be running the protocol
>and not just a fixed instance or only one.
>
>> 
>> 3)  Personally, I hate counting serial ports from 1, everybody knows
>> that computers count from 0.  I'd refer to it as which `ttyS' port to
>> use, starting from 0, but I'm willing to live with the COM 
>terminology.
>
>Me, too.  I decided to follow the COM1/COM2/COM3/COM4 nomenclature as
>this felt more like the PC hardware choice rather than an OS specific
>choice.  I'd guess that Windows people won't be using ttyS, 
>for instance.
>
>How do you think we should proceed with this ?  My goal is quite
>simple: allow some set (including none) of the serial lines to be
>created and use the Summagraphics protocol (or not).
>
>Does this make sense, or have I totally misunderstood something ?
>
>
>Thanks,
>-b
>
>> --
>> Don Dugger
>> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>> Donald.D.Dugger@xxxxxxxxx
>> Ph: (303)440-1368 
>> 
>> 
>>>-----Original Message-----
>>>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>>>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
>Ben Thomas
>>>Sent: Thursday, May 18, 2006 12:50 PM
>>>To: xen-devel@xxxxxxxxxxxxxxxxxxx
>>>Subject: [Xen-devel] [PATCH] - make qemu serial summagraphics 
>>>settings a bitmore fluid
>>>
>>>Changeset 9967 made the qemu serial line Summagraphics 
>support a little
>>>more flexible with respect to the COM line chosen.  This patch
>>>furthers that effort by removing the COM2 restriction.  This patch
>>>allows a "-summa n" command line option to qemu to specify which, if
>>>any, COM port should be using the Summagraphics protocols.
>>>
>>>Signed-off-by: Ben Thomas (ben@xxxxxxxxxxxxxxx)
>>>
>>>-- 
>>>---------------------------------------------------------------
>>>---------
>>>Ben Thomas                                         Virtual 
>>>Iron Software
>>>bthomas@xxxxxxxxxxxxxxx                            Tower 1, Floor 2
>>>978-849-1214                                       900 
>>>Chelmsford Street
>>>                                                   Lowell, MA 01851
>>>
>
>
>-- 
>---------------------------------------------------------------
>---------
>Ben Thomas                                         Virtual 
>Iron Software
>bthomas@xxxxxxxxxxxxxxx                            Tower 1, Floor 2
>978-849-1214                                       900 
>Chelmsford Street
>                                                    Lowell, MA 01851
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.