3.0.3 without X

3.0.3 without X

[jason]

Hello,
    I have posted this to the users list, but haven't had much luck. 
I've also used my best google-fu, which may be lacking, and searched the 
archives. 

I run Dom0 in a very bare bones enviroment that fits on a CF card.  My 
DomUs then use my harddrives and Dom0 is left only wih the task of 
managing my DomUs. This has worked out really well for me using Xen 
3.0HG-Unstable (old old old).  I've tried to recently move to 3.0.3 and 
a new dependency on X Windows seems to have popped up. I can't get my 
compile to make it past the ioemu/vnc.c parts since I don't have 
anything resembling X installed.  Is their a way to compile 3.0.3 
without the X dependency?  I don't have any HVM hardware, so that's not 
a concern for me and I've already tried to edit config/x86_32.mk. 

Thanks!

/mnt/share/xen-3.0.3_0-src/tools/ioemu/vnc.c:50:27: X11/keysymdef.h: No 
such file or directory
/mnt/share/xen-3.0.3_0-src/tools/ioemu/vnc.c: In function `do_key_event':

...blah blah blah...

/mnt/share/xen-3.0.3_0-src/tools/ioemu/vnc.c: In function 
`protocol_client_msg':
/mnt/share/xen-3.0.3_0-src/tools/ioemu/vnc.c:1069: warning: unused 
variable `now'
make[5]: *** [vnc.o] Error 1

-- 
Jason
The place where you made your stand never mattered,
only that you were there... and still on your feet

Re: 3.0.3 without X

[ron minnich]

note that we're distributing an x11-free xen for plan 9 support, so I
sure hope that x11 dependencies are not about to start appearing in
xen.

thanks

ron

Re: 3.0.3 without X

[Keir Fraser]

On 4/1/07 14:54, "jason" <fearthepenguin@jasonandjessi.com> wrote:

> I run Dom0 in a very bare bones enviroment that fits on a CF card.  My
> DomUs then use my harddrives and Dom0 is left only wih the task of
> managing my DomUs. This has worked out really well for me using Xen
> 3.0HG-Unstable (old old old).  I've tried to recently move to 3.0.3 and
> a new dependency on X Windows seems to have popped up. I can't get my
> compile to make it past the ioemu/vnc.c parts since I don't have
> anything resembling X installed.  Is their a way to compile 3.0.3
> without the X dependency?  I don't have any HVM hardware, so that's not
> a concern for me and I've already tried to edit config/x86_32.mk.

Remove references to 'ioemu' from tools/Makefile. If you don't use HVM
guests then you do not need to build or install anything in tools/ioemu.

 -- Keir

Re: 3.0.3 without X

[Keir Fraser]

On 4/1/07 14:58, "ron minnich" <rminnich@gmail.com> wrote:

> note that we're distributing an x11-free xen for plan 9 support, so I
> sure hope that x11 dependencies are not about to start appearing in
> xen.

The dependencies are only in HVM-specific bits of the tools/ directory.
Those are easily disabled, albeit with a smidgen of Makefile changes.

 -- Keir

Re: 3.0.3 without X

[Ewan Mellor]

On Thu, Jan 04, 2007 at 03:01:08PM +0000, Keir Fraser wrote:

> On 4/1/07 14:58, "ron minnich" <rminnich@gmail.com> wrote:
> 
> > note that we're distributing an x11-free xen for plan 9 support, so I
> > sure hope that x11 dependencies are not about to start appearing in
> > xen.
> 
> The dependencies are only in HVM-specific bits of the tools/ directory.
> Those are easily disabled, albeit with a smidgen of Makefile changes.

They also aren't really X11 dependencies.  That code includes
<X11/keysymdef.h>, because VNC uses the same keysyms as X, but there's no
dependency upon X client libraries.

Ewan.

Re: 3.0.3 without X

[ron minnich]

On 1/4/07, Ewan Mellor <ewan@xensource.com> wrote:

> They also aren't really X11 dependencies.  That code includes
> <X11/keysymdef.h>, because VNC uses the same keysyms as X, but there's no
> dependency upon X client libraries.

Thanks, I wonder if a note of some sort at the top level would be
useful to those of us who are not as familiar with the details as ...
we should be :-)

thanks!

ron

Re: 3.0.3 without X

[jason]

Thank you all, that worked like a charm!

ron minnich wrote:
> On 1/4/07, Ewan Mellor <ewan@xensource.com> wrote:
>
>> They also aren't really X11 dependencies.  That code includes
>> <X11/keysymdef.h>, because VNC uses the same keysyms as X, but 
>> there's no
>> dependency upon X client libraries.
>
> Thanks, I wonder if a note of some sort at the top level would be
> useful to those of us who are not as familiar with the details as ...
> we should be :-)
>
> thanks!
>
> ron
>
>

-- 
Jason
The place where you made your stand never mattered,
only that you were there... and still on your feet

Re: 3.0.3 without X

[Mark Williamson]

> Thanks, I wonder if a note of some sort at the top level would be
> useful to those of us who are not as familiar with the details as ...
> we should be :-)

Maybe we could have a top level compile option to disable building this stuff?  
It would seem a shame to make the builds less uniform but I guess it's also a 
shame to have to edit the Makefiles... ;-)

It'd only be a wafeur-thin patch...

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: 3.0.3 without X

[Anthony Liguori]

Ewan Mellor wrote:
> On Thu, Jan 04, 2007 at 03:01:08PM +0000, Keir Fraser wrote:
> 
>> On 4/1/07 14:58, "ron minnich" <rminnich@gmail.com> wrote:
>>
>>> note that we're distributing an x11-free xen for plan 9 support, so I
>>> sure hope that x11 dependencies are not about to start appearing in
>>> xen.
>> The dependencies are only in HVM-specific bits of the tools/ directory.
>> Those are easily disabled, albeit with a smidgen of Makefile changes.
> 
> They also aren't really X11 dependencies.  That code includes
> <X11/keysymdef.h>, because VNC uses the same keysyms as X, but there's no
> dependency upon X client libraries.

This dependency is actually a bug that was introduced in the Xen tree 
(it isn't present in qemu CVS).

The VNC spec makes it pretty clear that you cannot rely on the symbolic 
names of X keycodes to develop a portable VNC client.  Apparently they 
change slightly across different X implementations.

When I wrote the original VNC code for QEMU, I was careful not to rely 
on include files because of this.  We should really remove this 
dependency and hard code the keycodes ourself.

Regards,

Anthony Liguori


> Ewan.

Re: 3.0.3 without X

[Ewan Mellor]

On Thu, Jan 04, 2007 at 01:32:49PM -0600, Anthony Liguori wrote:

> Ewan Mellor wrote:
> >On Thu, Jan 04, 2007 at 03:01:08PM +0000, Keir Fraser wrote:
> >
> >>On 4/1/07 14:58, "ron minnich" <rminnich@gmail.com> wrote:
> >>
> >>>note that we're distributing an x11-free xen for plan 9 support, so I
> >>>sure hope that x11 dependencies are not about to start appearing in
> >>>xen.
> >>The dependencies are only in HVM-specific bits of the tools/ directory.
> >>Those are easily disabled, albeit with a smidgen of Makefile changes.
> >
> >They also aren't really X11 dependencies.  That code includes
> ><X11/keysymdef.h>, because VNC uses the same keysyms as X, but there's no
> >dependency upon X client libraries.
> 
> This dependency is actually a bug that was introduced in the Xen tree 
> (it isn't present in qemu CVS).
> 
> The VNC spec makes it pretty clear that you cannot rely on the symbolic 
> names of X keycodes to develop a portable VNC client.  Apparently they 
> change slightly across different X implementations.

>From www.realvnc.com/docs/rfbproto.pdf:

"The key itself is specified using the "keysym" values defined by the X Window
System.

For most ordinary keys, the "keysym" is the same as the corresponding
ASCII value.  For full details, see The Xlib Reference Manual, published by
O'Reilly & Associates, or see the header file <X11/keysymdef.h> from any X
Window System installation."


How do we choose which X keysyms to use, if they vary across X
implementations?

Ewan.

Re: 3.0.3 without X

[Anthony Liguori]

Ewan Mellor wrote:
> On Thu, Jan 04, 2007 at 01:32:49PM -0600, Anthony Liguori wrote:
> 
>> Ewan Mellor wrote:
>>> On Thu, Jan 04, 2007 at 03:01:08PM +0000, Keir Fraser wrote:
>>>
>>>> On 4/1/07 14:58, "ron minnich" <rminnich@gmail.com> wrote:
>>>>
>>>>> note that we're distributing an x11-free xen for plan 9 support, so I
>>>>> sure hope that x11 dependencies are not about to start appearing in
>>>>> xen.
>>>> The dependencies are only in HVM-specific bits of the tools/ directory.
>>>> Those are easily disabled, albeit with a smidgen of Makefile changes.
>>> They also aren't really X11 dependencies.  That code includes
>>> <X11/keysymdef.h>, because VNC uses the same keysyms as X, but there's no
>>> dependency upon X client libraries.
>> This dependency is actually a bug that was introduced in the Xen tree 
>> (it isn't present in qemu CVS).
>>
>> The VNC spec makes it pretty clear that you cannot rely on the symbolic 
>> names of X keycodes to develop a portable VNC client.  Apparently they 
>> change slightly across different X implementations.
> 
>>From www.realvnc.com/docs/rfbproto.pdf:
> 
> "The key itself is specified using the "keysym" values defined by the X Window
> System.
> 
> For most ordinary keys, the "keysym" is the same as the corresponding
> ASCII value.  For full details, see The Xlib Reference Manual, published by
> O'Reilly & Associates, or see the header file <X11/keysymdef.h> from any X
> Window System installation."

And then shortly following it goes on to describe how a number of keys 
are not universally represented like a backwards tab.

> 
> How do we choose which X keysyms to use, if they vary across X
> implementations?

By choosing keysyms that are known to work and not relying on buggy X 
implementations.

Regards,

Anthony Liguori

> Ewan.

Re: 3.0.3 without X

[Ewan Mellor]

On Thu, Jan 04, 2007 at 10:57:16AM -0700, ron minnich wrote:

> On 1/4/07, Ewan Mellor <ewan@xensource.com> wrote:
> 
> >They also aren't really X11 dependencies.  That code includes
> ><X11/keysymdef.h>, because VNC uses the same keysyms as X, but there's no
> >dependency upon X client libraries.
> 
> Thanks, I wonder if a note of some sort at the top level would be
> useful to those of us who are not as familiar with the details as ...
> we should be :-)

Certainly!  Patches to documentation such as the README and the user guide are
always welcome.  This is a great way that people can help out -- by writing
down the things that catch you out the first time around.

Ewan.

Re: 3.0.3 without X

[Ewan Mellor]

On Thu, Jan 04, 2007 at 03:17:02PM -0600, Anthony Liguori wrote:

> Ewan Mellor wrote:
> >On Thu, Jan 04, 2007 at 01:32:49PM -0600, Anthony Liguori wrote:
> >
> >>Ewan Mellor wrote:
> >>>On Thu, Jan 04, 2007 at 03:01:08PM +0000, Keir Fraser wrote:
> >>>
> >>>>On 4/1/07 14:58, "ron minnich" <rminnich@gmail.com> wrote:
> >>>>
> >>>>>note that we're distributing an x11-free xen for plan 9 support, so I
> >>>>>sure hope that x11 dependencies are not about to start appearing in
> >>>>>xen.
> >>>>The dependencies are only in HVM-specific bits of the tools/ directory.
> >>>>Those are easily disabled, albeit with a smidgen of Makefile changes.
> >>>They also aren't really X11 dependencies.  That code includes
> >>><X11/keysymdef.h>, because VNC uses the same keysyms as X, but there's no
> >>>dependency upon X client libraries.
> >>This dependency is actually a bug that was introduced in the Xen tree 
> >>(it isn't present in qemu CVS).
> >>
> >>The VNC spec makes it pretty clear that you cannot rely on the symbolic 
> >>names of X keycodes to develop a portable VNC client.  Apparently they 
> >>change slightly across different X implementations.
> >
> >>From www.realvnc.com/docs/rfbproto.pdf:
> >
> >"The key itself is specified using the "keysym" values defined by the X 
> >Window
> >System.
> >
> >For most ordinary keys, the "keysym" is the same as the corresponding
> >ASCII value.  For full details, see The Xlib Reference Manual, published by
> >O'Reilly & Associates, or see the header file <X11/keysymdef.h> from any X
> >Window System installation."
> 
> And then shortly following it goes on to describe how a number of keys 
> are not universally represented like a backwards tab.

Right, but we don't use any of those keysyms in the QEMU code -- we use the
widespread standard ones, like the navigation keys, shift and lock keys,
and the numpad.  Everything else is handled through the keymaps (which
behave wrt backward tab just as the spec describes). 

Ewan.

Dependency checking - early was Re: 3.0.3 without X

[Steve Kemp]

[-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --]

On Thu, Jan 04, 2007 at 10:31:14PM +0000, Ewan Mellor wrote:

> Certainly!  Patches to documentation such as the README and the user guide are
> always welcome.  This is a great way that people can help out -- by writing
> down the things that catch you out the first time around.

  I was about to report something like this myself this week.  Too often
 I install Xen on a new host and miss a dependency due to carelessness.

  Please find a patch below to "make world" which first runs "make tools/check"
 hopefully making sure that all dependencies are present and detected
 early.

  (Most frustrating is missing libssl, or libz, which is only otherwise
 detected right at the end of a kernel build.)

Steve
-- 

--- Makefile~   2006-12-23 21:17:38.000000000 +0000
+++ Makefile    2007-01-05 09:29:04.000000000 +0000
@@ -30,6 +30,13 @@
        $(MAKE) -C tools build
        $(MAKE) -C docs build

+#
+#  Check dependencies.
+#
+.PHONY: check
+check:
+       $(MAKE) -C tools/check
+
 # The test target is for unit tests that can run without an installation.  Of
 # course, many tests require a machine running Xen itself, and these are
 # handled elsewhere.
@@ -104,7 +111,7 @@
 # and place them in the install directory. 'make install' should then
 # copy them to the normal system directories
 .PHONY: world
-world:
+world: check
        $(MAKE) clean
        $(MAKE) kdelete
        $(MAKE) dist


[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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