Xen devel - Aug 2006 - mini-os: gnttab.c does not compile

Hello,

sorry to bother you with this: while trying to compile mini-os from 
xen-unstable.hg, I noticed that compilation failed like this:


gcc -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format 
-Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -m32 
-march=i686 -g -Iinclude  -Iinclude/x86      -Iinclude/x86/x86_32 -c gnttab.c 
-o gnttab.o
gnttab.c: In Funktion »init_gnttab«:
gnttab.c:165: error: request for member `p'' in something not a
structure or
union
make: *** [gnttab.o] Error 1

Looking at the source code, I''m not surprised that this happens, and I
suspect
that the file of the same name (gnttab.c) found in 
linux-2.6-xen-sparse/drivers/xen/core will also fail to compile (though I 
have not checked this).

It seems that the grant-table functions are currently in a non-functional 
state and that mini-os does not use these functions anyway (except for a call 
to the init function): After commenting out this call, I was able to build 
the mini-os binary.

Is there a particular reason for this? Can I expect the mini-os to work after  
removing gnttab.c?


Kind Regards

Rob

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

Hi there
Thanks for the reports guys.

I''m very busy for the next 2 days, but I will have a look afterwards.  
My guess is that public xen interfaces changed, which causes our  
grant table implementation to fail to compile.

If you remove gnttab.c (together with the init call from kernel.c)  
then Mini-OS should work just fine.

Cheers
Gregor
> Hello,
>
> sorry to bother you with this: while trying to compile mini-os from
> xen-unstable.hg, I noticed that compilation failed like this:
>
>
> gcc -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format
> -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -m32
> -march=i686 -g -Iinclude  -Iinclude/x86      -Iinclude/x86/x86_32 - 
> c gnttab.c
> -o gnttab.o
> gnttab.c: In Funktion »init_gnttab«:
> gnttab.c:165: error: request for member `p'' in something not a  
> structure or
> union
> make: *** [gnttab.o] Error 1
>
> Looking at the source code, I''m not surprised that this happens,  
> and I suspect
> that the file of the same name (gnttab.c) found in
> linux-2.6-xen-sparse/drivers/xen/core will also fail to compile  
> (though I
> have not checked this).
>
> It seems that the grant-table functions are currently in a non- 
> functional
> state and that mini-os does not use these functions anyway (except  
> for a call
> to the init function): After commenting out this call, I was able  
> to build
> the mini-os binary.
>
> Is there a particular reason for this? Can I expect the mini-os to  
> work after
> removing gnttab.c?
>
>
> Kind Regards
>
> Rob

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

Hello Gregor

Thanks for your response.

Grzegorz Milos schrieb:
> Hi there
> Thanks for the reports guys.
>
> I''m very busy for the next 2 days, but I will have a look
afterwards.
> My guess is that public xen interfaces changed, which causes our grant 
> table implementation to fail to compile.
>
> If you remove gnttab.c (together with the init call from kernel.c) 
> then Mini-OS should work just fine.
>
I switched to xen-3.0.2 for now. The mini-os here does compile, but it 
has some bugs too: Exception handling does not display the correct 
registers and gets into an endless loop. I have developed a patch to fix 
these issues. I suppose it would be best if I "forward-ported" this 
patch to xen-unstable and submit it to you?

Another issue I found is that mini-os blocks its VM when idle (I posted 
a question about this a few weeks ago, but didn''t get any response):
Xen
signals timer events to mini-os, but because mini-os is blocked most of 
the time, it misses roughly 99% of those. That is why the periodic 
output of the current time that mini-os is supposed to display does not 
show (actually it would if one were patient enough to wait for a few 
hours or even days..). This could be fixed easily by removing the 
blocking call.

Cheers

Rob
> Cheers
> Gregor
>
>> Hello,
>>
>> sorry to bother you with this: while trying to compile mini-os from
>> xen-unstable.hg, I noticed that compilation failed like this:
>>
>>
>> gcc -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format
>> -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -m32
>> -march=i686 -g -Iinclude  -Iinclude/x86      -Iinclude/x86/x86_32 -c 
>> gnttab.c
>> -o gnttab.o
>> gnttab.c: In Funktion »init_gnttab«:
>> gnttab.c:165: error: request for member `p'' in something not a
>> structure or
>> union
>> make: *** [gnttab.o] Error 1
>>
>> Looking at the source code, I''m not surprised that this
happens, and
>> I suspect
>> that the file of the same name (gnttab.c) found in
>> linux-2.6-xen-sparse/drivers/xen/core will also fail to compile 
>> (though I
>> have not checked this).
>>
>> It seems that the grant-table functions are currently in a 
>> non-functional
>> state and that mini-os does not use these functions anyway (except 
>> for a call
>> to the init function): After commenting out this call, I was able to 
>> build
>> the mini-os binary.
>>
>> Is there a particular reason for this? Can I expect the mini-os to 
>> work after
>> removing gnttab.c?
>>
>>
>> Kind Regards
>>
>> Rob
>

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

MiniOS wasn''t declaring a __XEN_INTERFACE_VERSION__, so it broke  
after the recent dom0_ops.h change.

I pushed a small Makefile fix so it declares it as 0x00030203 (the  
version right before those changes) and builds again.  Someone should  
also update it to sync with the new header files as well so that the  
interface version can bumped to the latest.

-anil

On 29 Aug 2006, at 13:42, Robert Kaiser (FH) wrote:
> Hello,
>
> sorry to bother you with this: while trying to compile mini-os from
> xen-unstable.hg, I noticed that compilation failed like this:
>
>
> gcc -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format
> -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -m32
> -march=i686 -g -Iinclude  -Iinclude/x86      -Iinclude/x86/x86_32 - 
> c gnttab.c
> -o gnttab.o
> gnttab.c: In Funktion »init_gnttab«:
> gnttab.c:165: error: request for member `p'' in something not a  
> structure or
> union
> make: *** [gnttab.o] Error 1
>
> Looking at the source code, I''m not surprised that this happens,  
> and I suspect
> that the file of the same name (gnttab.c) found in
> linux-2.6-xen-sparse/drivers/xen/core will also fail to compile  
> (though I
> have not checked this).
>
> It seems that the grant-table functions are currently in a non- 
> functional
> state and that mini-os does not use these functions anyway (except  
> for a call
> to the init function): After commenting out this call, I was able  
> to build
> the mini-os binary.
>
> Is there a particular reason for this? Can I expect the mini-os to  
> work after
> removing gnttab.c?
>
>
> Kind Regards
>
> Rob
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

On 31/8/06 12:11 pm, "Anil Madhavapeddy" <anil@xensource.com>
wrote:
> MiniOS wasn''t declaring a __XEN_INTERFACE_VERSION__, so it broke
> after the recent dom0_ops.h change.
> 
> I pushed a small Makefile fix so it declares it as 0x00030203 (the
> version right before those changes) and builds again.  Someone should
> also update it to sync with the new header files as well so that the
> interface version can bumped to the latest.
I wonder how it worked before? Set_xen_guest_handle() has never been a valid
thing for a guest to use if it doesn''t define a suitable
XEN_INTERFACE_VERSION. Going back to before the dom0_ops changes, the build
still fails for me: seems weird that gnttab.c could ever have built as part
of mini-os.

 -- Keir



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

On 1 Sep 2006, at 16:06, Keir Fraser wrote:
>
> On 31/8/06 12:11 pm, "Anil Madhavapeddy"
<anil@xensource.com> wrote:
>
>> MiniOS wasn''t declaring a __XEN_INTERFACE_VERSION__, so it
broke
>> after the recent dom0_ops.h change.
>>
>> I pushed a small Makefile fix so it declares it as 0x00030203 (the
>> version right before those changes) and builds again.  Someone should
>> also update it to sync with the new header files as well so that the
>> interface version can bumped to the latest.
>
> I wonder how it worked before? Set_xen_guest_handle() has never  
> been a valid
> thing for a guest to use if it doesn''t define a suitable
> XEN_INTERFACE_VERSION. Going back to before the dom0_ops changes,  
> the build
> still fails for me: seems weird that gnttab.c could ever have built  
> as part
> of mini-os.
It''s never compiled at all for me before :-)

I''ve had a "CFLAGS += -D__XEN__" local change to my checkout
of mini-
os for ages (thats not the right fix, but it worked too).

Grzegorz, how do you compile up mini-os normally?

-anil

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

Hi Gregor,

attached is a patch to mini-os. It removes the debug print of current time 
(which didnt work anyway) and adds support for timed sleeps. The application 
code now has a thread which is activated periodically (once every second) by 
means of the new sleep function and prints out the current time, so the 
program now actually does what the README says. The idle thread now blocks as 
long as necessary (i.e. until the nearest timeout expires) instead if the 
fixed 10 seconds as before.

Please review it and consider for inclusion.

Cheers

Rob


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

Hi Robert,

Having timeout timers in MiniOS would be very useful indeed (I had a  
few people asking about that already).

Timers in Xen and Linux are a bit different then your implementation  
for MiniOS (inspect xen/common/timer.c and <linux>/kernel/timer.c for  
more detail). The way that Linux/Xen handles timers is slightly more  
flexible, however the functionality that you could put in Mini-OS  
timer handler is very limited (you can only wake up a thread/set of  
threads really). I think we can therefore stick to this solution for  
now. I''ll have a look through the code tomorrow, and let you know if  
I have any comments.

Thanks.
Gregor

On 1 Oct 2006, at 00:18, Robert Kaiser (FH) wrote:
> Hi Gregor,
>
> attached is a patch to mini-os. It removes the debug print of  
> current time
> (which didnt work anyway) and adds support for timed sleeps. The  
> application
> code now has a thread which is activated periodically (once every  
> second) by
> means of the new sleep function and prints out the current time, so  
> the
> program now actually does what the README says. The idle thread now  
> blocks as
> long as necessary (i.e. until the nearest timeout expires) instead  
> if the
> fixed 10 seconds as before.
>
> Please review it and consider for inclusion.
>
> Cheers
>
> Rob
> <minios.patch>

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

Hi Gregor

Am Sonntag, 1. Oktober 2006 20:38 schrieb Grzegorz
Milos:
> Hi Robert,
>
> Having timeout timers in MiniOS would be very useful indeed (I had a
> few people asking about that already).
>
> Timers in Xen and Linux are a bit different then your implementation
> for MiniOS (inspect xen/common/timer.c and <linux>/kernel/timer.c for
> more detail). The way that Linux/Xen handles timers is slightly more
> flexible, however the functionality that you could put in Mini-OS
> timer handler is very limited (you can only wake up a thread/set of
> threads really).
Which functionalities would you like to see that are currently missing? 
> I think we can therefore stick to this solution for 
> now. I''ll have a look through the code tomorrow, and let you know
if
> I have any comments.
Thanks.

(There are few shortcomings of my implementation that I''m well aware of
myself. For instance, I think it would be more efficient to unlink blocked 
threads from the ready queue and keep the ones with pending timeouts in a 
"timeout" queue, sorted by ascending expiry date.  That way, it
wouldn''t be
necessary to walk the entire ready queue all the time to see if any timeouts 
have expired: it would suffice to just look at the head of the timeout queue. 
However, my goal was to keep things simple and to not change more than 
absolutely necessary.)

Cheers

Rob
>
> Thanks.
> Gregor
>
> On 1 Oct 2006, at 00:18, Robert Kaiser (FH) wrote:
> > Hi Gregor,
> >
> > attached is a patch to mini-os. It removes the debug print of
> > current time
> > (which didnt work anyway) and adds support for timed sleeps. The
> > application
> > code now has a thread which is activated periodically (once every
> > second) by
> > means of the new sleep function and prints out the current time, so
> > the
> > program now actually does what the README says. The idle thread now
> > blocks as
> > long as necessary (i.e. until the nearest timeout expires) instead
> > if the
> > fixed 10 seconds as before.
> >
> > Please review it and consider for inclusion.
> >
> > Cheers
> >
> > Rob
> > <minios.patch>
-- 
Robert Kaiser

SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany
Tel.: +49-6136-814791 / Fax: +49-6136-9948-10
Email: robert.kaiser@sysgo.com / Web: http://www.sysgo.com


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

> Which functionalities would you like to see that are currently  
> missing?
The timers I was thinking about would follow Xen/Linux model. For  
each timer you would need to specify the following:
- a timeout (timestamp)
- a handler function
- if the timer is one-shot or periodic

Such timers are more flexible, but the handler function is limited in  
functionality by the fact that you are running in the interrupt  
context. Since Mini-OS doesn''t maintain much state (that could be  
modified by a timeout timer), the only thing you would be likely  
doing is waking up a thread/set of threads. It therefore follows that  
your implementation does the same thing, but it''s shorter/cleaner. In  
particular there is no need for timer heap or a similar datastructure.
>
> (There are few shortcomings of my implementation that I''m well  
> aware of
> myself. For instance, I think it would be more efficient to unlink  
> blocked
> threads from the ready queue and keep the ones with pending  
> timeouts in a
> "timeout" queue, sorted by ascending expiry date.  That way, it  
> wouldn''t be
> necessary to walk the entire ready queue all the time to see if any  
> timeouts
> have expired: it would suffice to just look at the head of the  
> timeout queue.
> However, my goal was to keep things simple and to not change more than
> absolutely necessary.)
That''s fine. I decided against separate lists for runnable/blocked  
threads for exactly the same reasons. Mini-OS is not about  
scalability, keeping the things as simple as possible is the main  
priority.

Cheers
Gregor

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

Ok, I''ve looked through the patch.

It''s simple enough. Everything seems to work fine (after
recompilation).

Keir could you apply the patch to unstable.

Thanks
Gregor
On 2 Oct 2006, at 09:02, Robert Kaiser wrote:
> Hi Gregor
>
> Am Sonntag, 1. Oktober 2006 20:38 schrieb Grzegorz Milos:
>> Hi Robert,
>>
>> Having timeout timers in MiniOS would be very useful indeed (I had a
>> few people asking about that already).
>>
>> Timers in Xen and Linux are a bit different then your implementation
>> for MiniOS (inspect xen/common/timer.c and <linux>/kernel/timer.c
for
>> more detail). The way that Linux/Xen handles timers is slightly more
>> flexible, however the functionality that you could put in Mini-OS
>> timer handler is very limited (you can only wake up a thread/set of
>> threads really).
>
> Which functionalities would you like to see that are currently  
> missing?
>
>> I think we can therefore stick to this solution for
>> now. I''ll have a look through the code tomorrow, and let you
know if
>> I have any comments.
>
> Thanks.
>
> (There are few shortcomings of my implementation that I''m well  
> aware of
> myself. For instance, I think it would be more efficient to unlink  
> blocked
> threads from the ready queue and keep the ones with pending  
> timeouts in a
> "timeout" queue, sorted by ascending expiry date.  That way, it  
> wouldn''t be
> necessary to walk the entire ready queue all the time to see if any  
> timeouts
> have expired: it would suffice to just look at the head of the  
> timeout queue.
> However, my goal was to keep things simple and to not change more than
> absolutely necessary.)
>
> Cheers
>
> Rob
>
>>
>> Thanks.
>> Gregor
>>
>> On 1 Oct 2006, at 00:18, Robert Kaiser (FH) wrote:
>>> Hi Gregor,
>>>
>>> attached is a patch to mini-os. It removes the debug print of
>>> current time
>>> (which didnt work anyway) and adds support for timed sleeps. The
>>> application
>>> code now has a thread which is activated periodically (once every
>>> second) by
>>> means of the new sleep function and prints out the current time, so
>>> the
>>> program now actually does what the README says. The idle thread now
>>> blocks as
>>> long as necessary (i.e. until the nearest timeout expires) instead
>>> if the
>>> fixed 10 seconds as before.
>>>
>>> Please review it and consider for inclusion.
>>>
>>> Cheers
>>>
>>> Rob
>>> <minios.patch>
>
> -- 
> Robert Kaiser
>
> SYSGO AG
> Office Mainz
> Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany
> Tel.: +49-6136-814791 / Fax: +49-6136-9948-10
> Email: robert.kaiser@sysgo.com / Web: http://www.sysgo.com

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