oslib-devel — discussions about oslib development/bugs/ideas, and so on...

Re: [Oslib-devel] Argc & argv elaboration

[Paolo G. <pao...@ev...>]

Hi Luca, Hi Giacomo...

what I really think about this issue is that the whole _startup function
should be customizable by the user.

That is, if we are using oslib only all remains like that, if we are
using our kernel based on OsLib, we should be able to write our own
_startup functions.

In fact, if you remove the command line mangling part, it remains only a
bios_save() and a bios_restore().

If this way is taken, there is no more need to have the "MAIN" define to
use a predefined OsLib's main() function or the kernel's "init"
function...

what do you think about that??? the code would be something like the one
in the bottom of the mail... and it seems in my opinion more simple...

bye

PJ

xlib/x1.c

-------------

[....]
DWORD _stkbase;
DWORD _stktop;

/* This is some extra stuff we need to compile with argument    */
/* passing and math extensions                  */
DWORD _argc = 0;
typedef char *charp;
charp _argv[100];

#ifndef NO_MAIN

extern void main(int argc,char *argv[]);
extern void bios_save(void);
extern void bios_restore(void);

/* This is used in GNU-C to implement C++ constructors/destructors */
/* See the lib sources for more details                */
void __main(int argc, char **argv)
{
}


struct multiboot_info * mbi_address(void)
{
  /* This is declared in [wc32/gnu]\x0.[asm/s] */
  extern struct multiboot_info *mbi;

  return (mbi);
}

void _startup(void)
{
   [...] as now, but main and not MAIN at the end
}

#endif

On Wed, 2003-03-19 at 15:09, Giacomo Guidi wrote:
> I found that the cmdline inside the multiboot structure
> is modified by the argc,argv elaboration
> /oslib/xlib/x1.c
> 
> function _startup(void)
> 
> it cause a fail getting argc argv when the cmdline is reused outside
> the oslib (ex: s.ha.r.k.)
> 
> so I suggest this correction (diff) where I defined and use a temp var.
-- 
-----------------------------------------------------------------------
Paolo Gai - ReTiS Lab - PhD Student

Scuola Superiore S. Anna        Tel       : +39 050 883 451 
Polo S. Anna Valdera            Fax       : +39 050 883 452
viale Rinaldo Piaggio 34        e-mail    : pj...@ga...
56025 - Pontedera (PI) - ITALY  home page : http://feanor.sssup.it/~pj
------------------------------------------------------------------------
Per favore non mandatemi allegati in Word o PowerPoint.
(Please avoid sending me Word or PowerPoint attachments.)
Si veda (See) http://www.fsf.org/philosophy/no-word-attachments.html
------------------------------------------------------------------------

[Oslib-devel] Argc & argv elaboration

[Giacomo G. <gu...@li...>]

Hi all

I found that the cmdline inside the multiboot structure
is modified by the argc,argv elaboration

/oslib/xlib/x1.c

function _startup(void)

it cause a fail getting argc argv when the cmdline is reused outside
the oslib (ex: s.ha.r.k.)

so I suggest this correction (diff) where I defined and use a temp var.

Index: x1.c
===================================================================
RCS file: /home/cvs/cvsroot/shark/oslib/xlib/x1.c,v
retrieving revision 1.2
diff -u -r1.2 x1.c
--- x1.c	30 Jan 2003 09:24:16 -0000	1.2
+++ x1.c	19 Mar 2003 13:05:25 -0000
@@ -98,6 +98,7 @@
  void _startup(void)
  {
    register int i = 0;
+  char temp[1000];
    struct multiboot_info *mbi = mbi_address();
    char *cmdline = (char *)(mbi->cmdline);

@@ -105,16 +106,21 @@
      cputs("X/Runtime library error!!! Unable to find memory 
information!\n");
      l1_exit(-1);
    }
-	
+
    if (mbi->flags & MB_INFO_CMDLINE) {
      /* Build parameter list, up to 100 parms... */
-    while (cmdline[i] != 0) {
-      _argv[_argc] = &(cmdline[i]);
-      while (cmdline[i] != ' ' && cmdline[i] != 0) i++;
+    while (cmdline[i] != 0 && i < 1000) {
+      temp[i] = cmdline[i];
+      _argv[_argc] = &(temp[i]);
+      while (cmdline[i] != ' ' && cmdline[i] != 0 && i < 1000) {
+        temp[i] = cmdline[i];
+        i++;
+      }
        if (cmdline[i] == ' ') {
-	cmdline[i] = 0; i++; _argc++;
+	temp[i] = 0; i++; _argc++;
        }
      }
+    temp[i] = 0;
      _argc++;
    }

@@ -122,15 +128,16 @@
    /* Call main procedure using standard C convention   */
    /* Remember you cannot call any console I/O function */
    /* if you do not call bios_save()            */
-	
+
+
  #ifdef __DUMP_MEM__
    message("X/MEM   : %u\n",mbi->mem_upper);
    message("DOS/MEM : %u\n",mbi->mem_lower);
    message("x_bios Size : %u\n",sizeof(X_BIOSCALL));
    message("mbi Size : %u\n",sizeof(struct multiboot_info));
    message("Cmdline : %s\n",mbi->cmdline);
-  message("Argc : %u",_argc);
-  message("Argv[0] : %s / %s\n",_argv[0]);
+  message("Argc : %u\n",_argc);
+  message("Argv[0] : %s\n",_argv[0]);
    message("Argv[1] : %s\n",_argv[1]);
    message("Argv[2] : %s\n",_argv[2]);
    message("Argv[3] : %s\n",_argv[3]);

[Oslib-devel] New oslib example

[Luca A. <la...@mb...>]

Hi all,

I just committed an example (examples/pitdemo.c) showing how to directly
program timer 0 for getting periodic timer interrupts. It is based on
the example posted by Juras yesterday.

Have a look at it...

			Luca
-- 
_________________________________________________________________________
Add this to your signature, if you think it is important
                       N O   W A R ! ! !

[Oslib-devel] PIT, the simplest example doesn't work

[Juras B. <yb...@tu...>]

Hello oslib-devel,


To clearfy I typed the simplest example of timer-using and
task-switching. The problem is that the timer IRQ handler
is called only once! :(

The make-file and the source follow:


=== makefile ===

BASE = /usr/local/oslib

include $(BASE)/config.mk

INCL   = $(BASE)
LIB_PATH    = $(BASE)/lib/
LIB_DIR  = $(BASE)\lib

OBJS = mtask.o

all: mtask.bin 

mtask.bin : $(OBJS)
        $(LD) $(LINK_OPT) $(LIB_PATH)x0.o $(OBJS) --start-group -lhc -lhx -lhm -lcons -lkl --end-group -o $@

=== end of makefile ===

=== mtask.c ===
#include <ll/stdlib.h>
#include <ll/sys/ll/ll-func.h>
#include <ll/i386/pit.h>
#include <ll/i386/pic.h>

CONTEXT thm,th0,th1;
CONTEXT contexts[3];
long active_c=0;

char stk0[256];
char stk1[256];

void timer_ev()
{
        active_c++;
        if (active_c>2) active_c=0;

        printf_xy(0,0,13,"T");

//      ll_context_to(contexts[active_c]); - works, but timer int is
// called once :(

}

void killer()
{
}

void procth0(void*p)
{
        while(1)
        {
                printf_xy(0,0,15,"0");

        }

}

void procth1(void*p)
{
        while(1)
        {
                printf_xy(0,0,15,"1");

        }

}


int main()
{
        ll_init();

        thm=ll_context_save();
        th0=ll_context_create(procth0,stk0,NULL,killer,0);
        th1=ll_context_create(procth1,stk1,NULL,killer,0);

        contexts[0]=thm;
        contexts[1]=th0;
        contexts[2]=th1;
        
        cli();
        pit_init(0,TMR_MD4,1000);
        l1_irq_bind(0,timer_ev);
        irq_unmask(0);
        sti();

        printf_xy(0,1,14,"Hello!");
        
        
        while(1)
        {
                printf_xy(0,0,15,"m");
        }

        
        return 0;
}
=== end of mtask.c ===

Why the timer handler is called only once?

-- 
Best regards,
 Juras                          mailto:yb...@tu...

[Oslib-devel] oslib, scheduler, events...

[Juras B. <yb...@tu...>]

Hello oslib-devel,

just a sample code that doesn't work. why?
And what does TIME_NEW mean? there's no even a track of it in the
documentation. ll_gettime prints "LL time panic". And event_post,
called from the event handler generates exception 13. :((((

What I want is a simple task-switching cycle.


#include <ll/i386/stdlib.h>
#include <ll/i386/cons.h>
#include <ll/i386/error.h>
#include <ll/i386/mem.h>
#include <ll/i386/mb-info.h>
#include <ll/i386/pic.h>
#include <ll/i386/pit.h>
#include <ll/i386/hw-instr.h>
#include <ll/i386/hw-func.h>
#include <ll/sys/ll/ll-func.h>
#include <ll/sys/ll/event.h>
#include <sd32/typfix.h>
#include <sd32/sdinit.h>

// temp vars

char stk1[4*100];
char stk2[4*100];

CONTEXT thm,th1,th2;

CONTEXT ctx[3];

char active=0;

char *vmem=0xB8000;

struct ll_initparms ei;
struct timespec ts,tn;

void pth1(void*p)
{
        while(1)
        {
                vmem[0]='1';
                //ll_context_load(thm);
        }

}

void pth2(void*p)
{
        while(1)
        {
                vmem[0]='2';
                //ll_context_load(thm);

        }

}

void klr()
{

}
void ev_hnd(void*p);



void ev_hnd(void*p)
{
        CONTEXT tc,cur;

        cur=ll_context_from();

        active++;
        if (active>2) active=0;

        tc=ctx[active];

//      ll_gettime(TIME_NEW,&ts);
        ADDNANO2TIMESPEC(100000000,&ts);
        event_post(ts,ev_hnd,NULL);
        vmem[1]=~vmem[1];
        
        ll_context_to(tc);
}

void sd32_init(void) // called after ll_init
{
        thm=ll_context_from();

        th1=ll_context_create(pth1,stk1,NULL,klr,0);
        th2=ll_context_create(pth2,stk2,NULL,klr,0);

        ctx[0]=thm;
        ctx[1]=th1;
        ctx[2]=th2;

        ei.mode=LL_PERIODIC;
        ei.tick=1000; //ms

        event_init(&ei); // if I try LL_ONESHOT, then there's an error message!!!

        NULL_TIMESPEC(&ts);
        ADDNANO2TIMESPEC(100000000,&ts);

//      ll_gettime(TIME_EXACT,0); - doesn't work also!!!
        
//      cli();
//      printf_xy(0,1,"timenew: %d, timexact: %d\n",ll_gettime(TIME_NEW,&ts),ll_gettime(TIME_EXACT,&ts));
//      sti();
//      ADDNANO2TIMESPEC(100000000,&ts);
        
        event_post(ts,ev_hnd,NULL);// calls event handler but after it
       // halts :(

        
        

        while(1)
        {
                
                vmem[0]='m';
                //ll_context_load(th1);
                //ll_context_load(th2);
                
        }

}
  

-- 
Best regards,
 Juras                          mailto:yb...@tu...

Re: [Oslib-devel] PIT... scheduler

[<luc...@em...>]

Hi Juras,

>   how to install a task scheduler? using pit_init(0,TMR_MD2,1) (from
>   the sources of xlib dir...) or by using events?
This is your choice ;) OSLib provides you the low-level functionalities
from xlib (l1_irq_bind() and pit_init()), or the higher level
functionalities from kl (the events). If you use events, you don't have
to care about programming the PIT, or explicitly setting an irq handler:
you simply call the event_post() interface (after calling event_init(),
of course ;), and it will do everything for you...

If you prefer the ``do it by yourself'' strategy, you can avoid using
events, and you can program the PIT and handle the PIT interrutp by
yourself... But this will be more complex, of course. 

> if using events, then the event handler must post another event,
> then exception 13 is generated...
Have a look at examples/scheddem.c: it does exactly what you need... And
it worked, last time that I checked ;-)

>   could you explain the parameters of pit_init? what mode should I
>   take, what channel, how to calculate appropriate const? I was
>   looking through the sources but the lack of comments...
pit_init(c, m, t) programs the PIT channel c to mode m and constant t.
The channel connected to the timer interrupt is channel 0 (i think ;),
and the modes that I generally use are mode 4 for generating periodic
interrupts, and mode 2 for generating one-shot interrupts. The value of
the time constant can be computed as <time in us> * 1197 / 1000.
Everything is explained a little bit better in the Intel docs ;)
Anyway, if you use events you do not have to care about these details.

			Luca
-- 
_________________________________________________________________________
Add this to your signature, if you think it is important
                       N O   W A R ! ! !

[Oslib-devel] PIT... scheduler

[Juras B. <yb...@tu...>]

Hello oslib-devel,

  how to install a task scheduler? using pit_init(0,TMR_MD2,1) (from
  the sources of xlib dir...) or
  by using events? if using events, then the event handler must post
  another event, then exception 13 is generated...

  could you explain the parameters of pit_init? what mode should I
  take, what channel, how to calculate appropriate const? I was
  looking through the sources but the lack of comments...

-- 
Best regards,
 Juras                          mailto:yb...@tu...

Re: [Oslib-devel] how to...

[Luca A. <luc...@em...>]

Hi Juras,

[...]

> Do you mean something like this:
> 
> void mytimerhandler()
> {
>  if (vm86task)
>   {
>    // jump to vm86 timer handler through real mode interrupt table
>    // by setting VM86 task's CS:IP pointer, pushing flags etc.
>    return;
>   }
> 
>   // switch to the next task in the scheduler's queue and
>   // handle timer interrupt for 32-bit OS needs
> 
> }
Yes, more or less... I don't know if the "jump to vm86 timer handler" part
is needed, hence I'd do something in the line of:

void mytimerhandler()
{
  if (<task is vm86>) {
    return;
  }

  <call scheduler and do your usual stuff>
}
 
> I think this will HALT the task-switching mechanism while a VM86-task is not
> yet finished and paralyze the system...
As I said, I would "play safe", and consider the vm86 task as nonpreemptable (or as the
highest priority task in a fixed priority scheduler).
This will surely have some effects on system latencies, but I don't think it will paralyze the
system. After verifying that this work, you can try more aggressive approaches, like
scheduling the vm86 task.

> But maybe I should handle an interrupt twice, i.e. emulate interrupt for VM86
> task (pushing flags, setting CS:IP...) and handle the interrupt as usual for OS
> needs?
I don't think this is needed. 

					Luca
-- 
                              N O    W A R ! ! !
     Copy this in your signature if you think it is important



--
Prendi GRATIS l'email universale che... risparmia: http://www.email.it/f

Sponsor:
Vai contro corrente! Inizia a mantenerti in forma da Natale: Oliviero Città dello Sport!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1074&d=2-3

Re[2]: [Oslib-devel] how to...

[Juras B. <yb...@tu...>]

Hello Luca,

Friday, February 28, 2003, 4:13:12 PM, you wrote:

LA> Ok, I hope this clarified things a little bit... If your scheduler is
LA> driven by the timer interrupt, I would simply avoid to invoke it if the
LA> interrupted task is the vm86 task.

Do you mean something like this:

void mytimerhandler()
{
 if (vm86task)
  {
   // jump to vm86 timer handler through real mode interrupt table
   // by setting VM86 task's CS:IP pointer, pushing flags etc.
   return;
  }

  // switch to the next task in the scheduler's queue and
  // handle timer interrupt for 32-bit OS needs

}

?

I think this will HALT the task-switching mechanism while a VM86-task is not
yet finished and paralyze the system...

But maybe I should handle an interrupt twice, i.e. emulate interrupt for VM86
task (pushing flags, setting CS:IP...) and handle the interrupt as usual for OS
needs?



-- 
Best regards,
 Juras                            mailto:yb...@tu...

Re: [Oslib-devel] how to...

[Luca A. <la...@mb...>]

Hi Juras,

sorry for the late reply...

>   how to obtain CONTEXT for VM86-task of callBIOS
>   to privide multitasking while a BIOS function is running?
Ok, here is how things work with vm86_callBIOS:
- There is a vm86 task that is used for performing bios calls. This is
  not a real task that can be scheduled together with the other ones (at
  least, I would not schedule it ;), but is considered to be
  nonpreemptable. It is only needed to switch to the vm86 mode (and
  back). It is not created through ll_context_create(), but by directly
  writing the TSS into the GDT (see vm86_init())
- The CONTEXT of a task is just a selector, indicating the position of
  its TSS in the GDT
- There is only a vm86 task (the BIOS is not reentrant), and its CONTEXT
  is X_VM86_TSS, defined in ll/i386/sel.h
- You can know the CONTEXT of the task that is currently running by
  using get_TR(), or context_save(), or ll_context_save() (they are more
  or less equivalent)
- Hence, if you want to see if you are running the vm86 task or not, you
  can do:
	CONTEXT c = get_TR();
	
	if (c == X_VM86_TSS) {
		/* We are in the vm86 task */
	} else {
		/* We are running some other task... */
	}
  See for example the emulate() function in examples/biosdemo.c

Ok, I hope this clarified things a little bit... If your scheduler is
driven by the timer interrupt, I would simply avoid to invoke it if the
interrupted task is the vm86 task.

				Luca

-- 
_________________________________________________________________________
Add this to your signature, if you think it is important
                       N O   W A R ! ! !

[Oslib-devel] how to...

[Juras B. <yb...@tu...>]

Hello oslib-devel,

  how to obtain CONTEXT for VM86-task of callBIOS
  to privide multitasking while a BIOS function is running?

-- 
Best regards,
 Juras                          mailto:yb...@tu...

Re: [Oslib-devel] oslib docs

[Luca A. <luc...@em...>]

Hi,

>  It's my first and test message to oslib-devel. I enumerate the main
>  ideas which must be described in the new documentation. (It's mainly from
>  our conversation with Luca).
[...]
Ok, it's on my todo list ;)
As soon as I'll find the time, I'll try to update & fix the documentation.
 
>  * LDT management
There is currently no plan for LDT management... I'll think about it when everything else will be ok ;)

>  Optional (not important by now):
> 
>  * multi-boot modules command, handling modules
[...]
Ok, I'll try to add something about it... For the moment, interested people can refer to the multiboot standard.


				Luca
-- 
                              N O    W A R ! ! !
     Copy this in your signature if you think it is important



--
Prendi GRATIS l'email universale che... risparmia: http://www.email.it/f

Sponsor:
Mobili da giardino, semi, piante, abbigliamento. Tutto questo (e molto altro...) lo trovi solo da Peraga.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=449&d=23-2

[Oslib-devel] oslib docs

[Juras B. <yb...@tu...>]

Hello All,

 It's my first and test message to oslib-devel. I enumerate the main
 ideas which must be described in the new documentation. (It's mainly from
 our conversation with Luca).

 * GDT, IDT state after l1_init, ll_init and
 security limitation for GDT_place, i.e. how to manage GDT/IDT in order not to
 hurt kernel library and hardware library assumptions (address space
 management, tss etc.), default handlers, making CS,DS,ES... to be
 zero-based and 4GB limited...
 * IRQ mapping (IDT entry "number X" handles IRQ "number Y")
 * LDT management
 * initialization (which one or both l1_init or ll_init?)
 * l1_ and ll_ collisions (what I can't use in hw lib while using
 kernel library)
 * memory allocation, what are the limits, internals, lacks of free()
 and alloc() provided by OSLib?
 * v86 usage limitations and assumptions, a note about BIOS... etc.

 Optional (not important by now):

 * multi-boot modules command, handling modules


-- 
Best regards,
 Juras                          mailto:yb...@tu...

[Oslib-devel] Re: Fw: OSLib

[<luc...@em...>]

Hello Juras,

since I am currently trying to support oslib, Gerardo forwarded me your
mail.

> ----- Original Message -----
> From: "Juras Ul. Benesh" <yb...@tu...>
> To: <lam...@ss...>
> Sent: Thursday, January 30, 2003 13:04
> Subject: OSLib
> 
> 
> > Hello g.lamastra,
> >
> > I'm very interested in oslib. To be short, I'm not satisfied that
> > with GRUB biosdemo.xtn doesn't work :((( What's wrong?
I just tried the cvs head of oslib, and it works both on my computer and on
bochs... But it can give problems if the bios of your video card tries
to call an interrupt. Hence, it may depend on your video card.

Anyway, to try to debug your problem I need more information:
1) Which version of oslib are you using? If it is not the current cvs
   head, please do a fresh checkout from the sourceforge cvs (you can
   use the anonymous access) and try again.
2) How are you compiling? From dos, or from linux? Which version of gcc
   are you using (gcc -v)?
3) How did you compile the demo? I assume you did something like
	cp mk/<proper config file>.mk config.mk
	make install
4) Which version of grub are you using?
5) What precisely happens when you try to boot the biosdemo? Does the
   computer reboot, does it hang, do you obtain some kind of unhandled
   exception, or does something else happens?
6) Which computer are you using? Which video card?


BTW, I am ccing the oslib devel mailing list, so that we can create some
traffic on it ;)

			Luca

-- 
_________________________________________________________________________
Add this to your signature, if you think it is important
                       N O   W A R ! ! !

[Oslib-devel] bug fixed, and tests with bochs

[luca a. <l_...@ho...>]

To everyone that is interested:

I just committed to the CVS repository a quick workaround for booting oslib 
programs with the newest grub versions.
As a consequence, the x.exe eXtender has been modified too. If you use the 
old version, oslib programs will not understand that they have been run 
through the extender (X_callBIOS() and DOS_*() functions will not be usable, 
the system will halt on exit, and so on...).
I'll commit the new eXtender in a short time.

I also downloaded the latest bochs snapshot, and tested all the oslib 
examples. In general, everything seems to work well.
There are only 2 problems:
1) sometime, the time (read from the PIT) seems to go back: the timetest.c 
program shows this problem by failing at line 68.
I still don't know if this is an oslib problem or a bochs problem, and I 
still have to investigate it (the test works fine on bare hardware, but I 
want to be sure before allarming bochs people).

2) the biosdemo.c test fails when returning from vm86 mode.
I think this is a bochs problem.
In fact, if you look in the bochs sources, in cpu/vm86.cc, you can see
BX_CPU_C::stack_return_from_v86(BxInstruction_t *i)
{
  //BX_INFO(("stack_return_from_v86:"));

  exception(BX_GP_EXCEPTION, 0, 0);
#if 0
  if (IOPL !=3) {
...

Hence, an iret in vm86 mode will always fail... I think this is wrong.
Changing it with
BX_CPU_C::stack_return_from_v86(BxInstruction_t *i)
{
  //BX_INFO(("stack_return_from_v86:"));
#if 0
  exception(BX_GP_EXCEPTION, 0, 0);
#else
  if (IOPL !=3) {
...

works better. Looking at the comments this code was probably disabled 
because some more check is needed... I don't know the bochs internals, hence 
I am completely clueless here...

Well, I think this is all for now

			Luca

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[Oslib-devel] Re: makefile in examples directory? & bug list

[luca a. <l_...@ho...>]

Hi Bryce,

>It would be great if you can document this.  It was reported as a
>potential bochs bug, and Sandro Magi and I spent quite a bit of time
>yesterday wondering if bochs was simulating it right or not.
Let me apologize for this. I never considered that not fixing that bug could 
cause a waste in other persons' time. I am really sorry.
As soon as possible I will commit a ``quick and dirty'' workarond on the 
CVS.

After that, I will download the latest bochs version, and try oslib examples 
on it. I'll let you know.

Also, thanks for submitting the bug reports on the sf page. I never used it 
because until few days ago I was the only oslib user and developer :)

				Luca

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[Oslib-devel] bug list

[Bryce D. <br...@tl...>]

I love the SF bug tracker, and we use it constantly on Bochs.  So I posted
the make problems and the grub 0.90 problem on your oslib bug list.

-Bryce

Re: [Oslib-devel] Re: makefile in examples directory?

[Bryce D. <br...@tl...>]

On Sun, 7 Oct 2001, luca abeni wrote:
> After unzipping the file, you will have to copy the correct mk/*.mk file in 
> config.mk, and do make install (make all will fail because it does not 
> install the libraries in the correct directory).
> That should produce all the .xtn files in the examples directory.

You're right...the makefile is there.  I was confused because of the
problem that you describe with make all, and then I was expecting a
makefile with a capital M so I didn't ever find it. :)  When I finally 
did make install, it worked.

[bryce@monster oslib]$ make
... lots of successful compiling ...
make[1]: Entering directory
`/usr/users/bryce/tlw/bochs/tstimg/oslib/oslib/examples'
make[1]: *** No rule to make target `mbdemo.xtn', needed by `all'.  Stop.

[bryce@monster oslib]$ make -C examples
make: Entering directory
`/usr/users/bryce/tlw/bochs/tstimg/oslib/oslib/examples'
make: *** No rule to make target `mbdemo.xtn', needed by `all'.  Stop.
make: Leaving directory
`/usr/users/bryce/tlw/bochs/tstimg/oslib/oslib/examples'

[bryce@monster oslib]$ make install
... some more compiling and linking ...
and it worked.

> Let me know if you have other problems.
> (Warning!!! Due to a known bug in oslib - I never had the time to fix it -, 
> the most recent versions of GRUB cannot be used... I am currently using 
> version 0.5.95)

It would be great if you can document this.  It was reported as a
potential bochs bug, and Sandro Magi and I spent quite a bit of time
yesterday wondering if bochs was simulating it right or not.  It seems
like the initial test for the a usable GDT is not good enough, and you
should just set up your own GDT every time.

 /* Test if GDT is usable */
  movl    %gs:0(%ebx),%ecx
  andl    $0x080,%ecx
  jnz     GDT_is_OK

With grub 0.90, it takes the branch and assumes the preexisting GDT is
usable, when in fact it's not.  The GDT limit is 0x27 and you use selector
0x30 (index 6) which is beyond the end of the GDT table.  See my analysis
at

http://sourceforge.net/tracker/index.php?func=detail&aid=468563&group_id=12580&atid=112580

> As a side note, I tried to run some oslib examples on bochs some time ago, 
> but my code uses some strange PIT modes that were not supported by bochs. I 
> see that the current version of bochs implements a more complete PIT model, 
> hence I will try it again, and I'll let you know the results.

Super!  Testing bochs with lots of little open-source examples is a great
way to get things fixed.  So many of our bug reports are problems that
occur millions of cycles into a windows boot or something, so it's nearly
impossible for us to reproduce the conditions exactly.  And in many cases,
it would be illegal for the user to send us disk images for debugging.  
Now that I know about oslib tests, I will probably use them for bochs vs
physical hardware testing as well.

Thanks a lot for your help!
Regards,
Bryce

[Oslib-devel] Re: makefile in examples directory?

[luca a. <l_...@ho...>]

Hi Bryce,

First of all, thanks for getting interested in oslib. I hope that it will be 
usefull to test bochs (BTW, thanks for all the great work that all you bochs 
guys are doing).

Coming to your problem, I think you are experiencing some kind of 
downloading fault...
Which sources are you using? Did you download the 0.1 release (osl-0-1.zip), 
the latest snapshot, or did you do a checkout from the CVS?

I just checked the CVS from the web interface, and the examples makefile is 
there... It also is in the 0.1 zip file.
So, I hope that downloading the 0.1 release from 
http://sourceforge.net/projects/oslib/
(or doing a CVS checkout from scratch) will solve your problem.

After unzipping the file, you will have to copy the correct mk/*.mk file in 
config.mk, and do make install (make all will fail because it does not 
install the libraries in the correct directory).
That should produce all the .xtn files in the examples directory.

Let me know if you have other problems.
(Warning!!! Due to a known bug in oslib - I never had the time to fix it -, 
the most recent versions of GRUB cannot be used... I am currently using 
version 0.5.95)

As a side note, I tried to run some oslib examples on bochs some time ago, 
but my code uses some strange PIT modes that were not supported by bochs. I 
see that the current version of bochs implements a more complete PIT model, 
hence I will try it again, and I'll let you know the results.

                                Luca

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[Oslib-devel] makefile in examples directory?

[Bryce D. <bry...@ya...>]

I'm trying to build the oslib tests in order to help test the Bochs x86
emulator (http://bochs.sf.net).  Maybe it's obvious to everyone else, but
I can't figure out how to build the examples because there is no makefile
in that directory.  I can build cpudemo.o and vmdemo.o and pitsdemo.o, but
the docs mention an .xtn file, which I don't know how to make.

Once you compile the cpudemo.c file, for example, how do you transform
that into something you can load in Grub or the eXtender?

Thanks,
Bryce


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

[Oslib-devel] Test...

[Luca A. <lu...@cs...>]

OK, let's be original...
Let's say: ``Test!!!''

			Luca