mini-os: gnttab.c does not compile

mini-os: gnttab.c does not compile

[Robert Kaiser (FH)]

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

Re: mini-os: gnttab.c does not compile

[Grzegorz Milos]

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

Re: mini-os: more bugs (was: mini-os: gnttab.c does not compile)

[Robert Kaiser (FH)]

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
>

Re: mini-os: gnttab.c does not compile

[Anil Madhavapeddy]

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

Re: mini-os: gnttab.c does not compile

[Keir Fraser]

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

Re: mini-os: gnttab.c does not compile

[Anil Madhavapeddy]

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

[PATCH] add timeouts to mini-os

[Robert Kaiser (FH)]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

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

[-- Attachment #2: minios.patch --]
[-- Type: text/x-diff, Size: 8157 bytes --]

diff -r 9977b8785570 extras/mini-os/README
--- a/extras/mini-os/README	Fri Sep 29 19:12:15 2006 +0100
+++ b/extras/mini-os/README	Sun Oct 01 00:56:02 2006 +0200
@@ -26,5 +26,5 @@ Stuff it doesn't show:
 - to start it do the following in domain0 (assuming xend is running)
   # xm create domain_config
 
-this starts the kernel and prints out a bunch of stuff and then every
-1000 timer interrupts the system time.
+this starts the kernel and prints out a bunch of stuff and then once
+every second the system time.
diff -r 9977b8785570 extras/mini-os/include/sched.h
--- a/extras/mini-os/include/sched.h	Fri Sep 29 19:12:15 2006 +0100
+++ b/extras/mini-os/include/sched.h	Sun Oct 01 00:34:44 2006 +0200
@@ -2,6 +2,7 @@
 #define __SCHED_H__
 
 #include <list.h>
+#include <time.h>
 
 struct thread
 {
@@ -11,6 +12,7 @@ struct thread
     unsigned long ip;  /* Instruction pointer */
     struct list_head thread_list;
     u32 flags;
+    s_time_t wakeup_time;
 };
 
 
@@ -36,5 +38,6 @@ static inline struct thread* get_current
 
 void wake(struct thread *thread);
 void block(struct thread *thread);
+void sleep(u32 millisecs);
 
 #endif /* __SCHED_H__ */
diff -r 9977b8785570 extras/mini-os/include/time.h
--- a/extras/mini-os/include/time.h	Fri Sep 29 19:12:15 2006 +0100
+++ b/extras/mini-os/include/time.h	Sun Oct 01 00:35:36 2006 +0200
@@ -7,8 +7,9 @@
  *        File: time.h
  *      Author: Rolf Neugebauer (neugebar@dcs.gla.ac.uk)
  *     Changes: Grzegorz Milos (gm281@cam.ac.uk)
+ *              Robert Kaiser (kaiser@informatik.fh-wiesbaden.de)
  *              
- *        Date: Jul 2003, changesJun 2005
+ *        Date: Jul 2003, changes: Jun 2005, Sep 2006
  * 
  * Environment: Xen Minimal OS
  * Description: Time and timer functions
@@ -57,7 +58,8 @@ void     init_time(void);
 void     init_time(void);
 s_time_t get_s_time(void);
 s_time_t get_v_time(void);
+u64      monotonic_clock(void);
 void     gettimeofday(struct timeval *tv);
-void     block_domain(u32 millisecs);
+void     block_domain(s_time_t until);
 
 #endif /* _TIME_H_ */
diff -r 9977b8785570 extras/mini-os/kernel.c
--- a/extras/mini-os/kernel.c	Fri Sep 29 19:12:15 2006 +0100
+++ b/extras/mini-os/kernel.c	Sun Oct 01 00:37:22 2006 +0200
@@ -6,6 +6,7 @@
  * 
  * Copyright (c) 2002-2003, K A Fraser & R Neugebauer
  * Copyright (c) 2005, Grzegorz Milos, Intel Research Cambridge
+ * Copyright (c) 2006, Robert Kaiser, FH Wiesbaden
  * 
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to
@@ -66,11 +67,24 @@ void xenbus_tester(void *p)
     /* test_xenbus(); */
 }
 
+void periodic_thread(void *p)
+{
+    struct timeval tv;
+    printk("Periodic thread started.\n");
+    for(;;)
+    {
+        gettimeofday(&tv);
+        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
+        sleep(1000);
+    }
+}
+
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
 {
     printk("Dummy main: start_info=%p\n", si);
     create_thread("xenbus_tester", xenbus_tester, si);
+    create_thread("periodic_thread", periodic_thread, si);
     return 0;
 }
 
diff -r 9977b8785570 extras/mini-os/sched.c
--- a/extras/mini-os/sched.c	Fri Sep 29 19:12:15 2006 +0100
+++ b/extras/mini-os/sched.c	Sun Oct 01 00:50:49 2006 +0200
@@ -5,7 +5,7 @@
  *
  *        File: sched.c
  *      Author: Grzegorz Milos
- *     Changes: 
+ *     Changes: Robert Kaiser
  *              
  *        Date: Aug 2005
  * 
@@ -142,6 +142,54 @@ void inline print_runqueue(void)
     printk("\n");
 }
 
+/* Find the time when the next timeout expires. If this is more than
+   10 seconds from now, return 10 seconds from now. */
+static s_time_t blocking_time(void)
+{
+    struct thread *thread;
+    struct list_head *iterator;
+    s_time_t min_wakeup_time;
+    unsigned long flags;
+    local_irq_save(flags);
+    /* default-block the domain for 10 seconds: */
+    min_wakeup_time = NOW() + SECONDS(10);
+
+    /* Thread list needs to be protected */
+    list_for_each(iterator, &idle_thread->thread_list)
+    {
+        thread = list_entry(iterator, struct thread, thread_list);
+        if(!is_runnable(thread) && thread->wakeup_time != 0LL)
+        {
+            if(thread->wakeup_time < min_wakeup_time)
+            {
+                min_wakeup_time = thread->wakeup_time;
+            }
+        }
+    }
+    local_irq_restore(flags);
+    return(min_wakeup_time);
+}
+
+/* Wake up all threads with expired timeouts. */
+static void wake_expired(void)
+{
+    struct thread *thread;
+    struct list_head *iterator;
+    s_time_t now = NOW();
+    unsigned long flags;
+    local_irq_save(flags);
+    /* Thread list needs to be protected */
+    list_for_each(iterator, &idle_thread->thread_list)
+    {
+        thread = list_entry(iterator, struct thread, thread_list);
+        if(!is_runnable(thread) && thread->wakeup_time != 0LL)
+        {
+            if(thread->wakeup_time <= now)
+                wake(thread);
+        }
+    }
+    local_irq_restore(flags);
+}
 
 void schedule(void)
 {
@@ -229,8 +277,9 @@ struct thread* create_thread(char *name,
     stack_push(thread, (unsigned long) data);
     thread->ip = (unsigned long) thread_starter;
      
-    /* Not runable, not exited */ 
+    /* Not runable, not exited, not sleeping */
     thread->flags = 0;
+    thread->wakeup_time = 0LL;
     set_runnable(thread);
     local_irq_save(flags);
     if(idle_thread != NULL) {
@@ -247,20 +296,34 @@ struct thread* create_thread(char *name,
 
 void block(struct thread *thread)
 {
+    thread->wakeup_time = 0LL;
     clear_runnable(thread);
 }
 
+void sleep(u32 millisecs)
+{
+    struct thread *thread = get_current();
+    thread->wakeup_time = NOW()  + MILLISECS(millisecs);
+    clear_runnable(thread);
+    schedule();
+}
+
 void wake(struct thread *thread)
 {
+    thread->wakeup_time = 0LL;
     set_runnable(thread);
 }
 
 void idle_thread_fn(void *unused)
 {
+    s_time_t until;
     for(;;)
     {
         schedule();
-        block_domain(10000);
+        /* block until the next timeout expires, or for 10 secs, whichever comes first */
+        until = blocking_time();
+        block_domain(until);
+        wake_expired();
     }
 }
 
@@ -278,7 +341,7 @@ void run_idle_thread(void)
                          "push %1\n\t" 
                          "ret"                                            
                          :"=m" (idle_thread->sp)
-                         :"m" (idle_thread->ip));                          
+                         :"m" (idle_thread->ip));                                                    
 #endif
 }
 
diff -r 9977b8785570 extras/mini-os/time.c
--- a/extras/mini-os/time.c	Fri Sep 29 19:12:15 2006 +0100
+++ b/extras/mini-os/time.c	Sun Oct 01 00:31:41 2006 +0200
@@ -3,6 +3,7 @@
  * (C) 2003 - Rolf Neugebauer - Intel Research Cambridge
  * (C) 2002-2003 - Keir Fraser - University of Cambridge 
  * (C) 2005 - Grzegorz Milos - Intel Research Cambridge
+ * (C) 2006 - Robert Kaiser - FH Wiesbaden
  ****************************************************************************
  *
  *        File: time.c
@@ -194,21 +195,15 @@ void gettimeofday(struct timeval *tv)
 }
 
 
-static void print_current_time(void)
-{
-    struct timeval tv;    
-
-    gettimeofday(&tv);
-    printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
-}
-
-
-void block_domain(u32 millisecs)
+void block_domain(s_time_t until)
 {
     struct timeval tv;
     gettimeofday(&tv);
-    HYPERVISOR_set_timer_op(monotonic_clock() + 1000000LL * (s64) millisecs);
-    HYPERVISOR_sched_op(SCHEDOP_block, 0);
+    if(monotonic_clock() < until)
+    {
+        HYPERVISOR_set_timer_op(until);
+        HYPERVISOR_sched_op(SCHEDOP_block, 0);
+    }
 }
 
 
@@ -217,15 +212,8 @@ void block_domain(u32 millisecs)
  */
 static void timer_handler(evtchn_port_t ev, struct pt_regs *regs, void *ign)
 {
-    static int i;
-
     get_time_values_from_xen();
     update_wallclock();
-    i++;
-    if (i >= 1000) {
-        print_current_time();
-        i = 0;
-    }
 }
 
 

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

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

Re: [PATCH] add timeouts to mini-os

[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). 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>

Re: [PATCH] add timeouts to mini-os

[Robert Kaiser]

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

Re: [PATCH] add timeouts to mini-os

[Grzegorz Milos]

> 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

Re: [PATCH] add timeouts to mini-os

[Grzegorz Milos]

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

Re: [PATCH] add timeouts to mini-os

[John D. Ramsdell]

The last message I saw about adding timeouts to mini-os was Greg
asking that the patches be applied on Oct 2nd.  Just today, I did a
pull of xen-unstable.hg, and I still see no changes to
extras/mini-os/time.c.  What happened to this patch?

John

Re: [PATCH] add timeouts to mini-os

[John D. Ramsdell]

> From: ramsdell@mitre.org (John D. Ramsdell)
..
> The last message I saw about adding timeouts to mini-os was Greg
> asking that the patches be applied on Oct 2nd.  Just today, I did a
> pull of xen-unstable.hg, and I still see no changes to
> extras/mini-os/time.c.  What happened to this patch?

Never mind.  I forgot that xen-unstable was closed for business.

John