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
Robert Kaiser (FH)
2006-Aug-30 21:29 UTC
[Xen-devel] Re: mini-os: more bugs (was: mini-os: gnttab.c does not compile)
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
Anil Madhavapeddy
2006-Aug-31 11:11 UTC
Re: [Xen-devel] mini-os: gnttab.c does not compile
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
Anil Madhavapeddy
2006-Sep-01 15:10 UTC
Re: [Xen-devel] mini-os: gnttab.c does not compile
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