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

Re: [Oslib-devel] using BIOS...

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

Hi Juras,
 
>   Will you be so kind to write an example of BIOS read sector call?
>   I spent several hours examining FD32's biosdisk driver and oslib's
>   sources and all my trials were a grand failure.
I'll try to cook up something during my lunch break ;-)

>   The first thing I met, examining biosdisk driver and current oslib
>   is that in biosdisk IRQ 6 is supposed to be 0x56 while oslib defines
>   IRQ 6 to 0x46... ok. The second is IDT_place instead of l1_int_bind.
>   Ok, biosdisk used an older version of OSLib.
Look at the "newoslib" branch in the freedos-32 cvs...

>   But then I couldn't realize why the 0x15
>   exception (reserved by Intel) is handled. And deeper the worse...
See my answer to your previous mail...

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



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
 nuovissimo Sony Ericsson T68i  marchiato TIM
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=552&d=5-5

[Oslib-devel] using BIOS...

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

Hello OSLib Developers,

  Will you be so kind to write an example of BIOS read sector call?
  I spent several hours examining FD32's biosdisk driver and oslib's
  sources and all my trials were a grand failure.

  The first thing I met, examining biosdisk driver and current oslib
  is that in biosdisk IRQ 6 is supposed to be 0x56 while oslib defines
  IRQ 6 to 0x46... ok. The second is IDT_place instead of l1_int_bind.
  Ok, biosdisk used an older version of OSLib.
  But then I couldn't realize why the 0x15
  exception (reserved by Intel) is handled. And deeper the worse...

  At last, I ask you for help. The "biosdemo.c" is good but the better
  would be a demo which uses kernel library (ll_ functions) and calls
  BIOS Disk Services. I use contexts and events so I need your help.
  Nowhere in the sources is clearified what parameters gets
  interrupt/irq handler set by irq_bind or int_bind and l1_int_bind...

  Please, help. Thank you for your time.

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

Re: [Oslib-devel] irq_bind, int_bind etc

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

Hi Juras,

>   What's the difference between irq_bind and l1_irq_bind ?
irq_bind is a kl function: it supports the ``event interface'', and is
safer to use when you are doing multitasking.
l1_irq_bind is a lower level function (it directly accesses the xlib
mechanism that is used by irq_bind). If you use it, you will have less
overhead in interrupt management (you can save one indirection), but
things become tricky when you do multitasking.
 
>   what's the function's prototype which is called on an interrupt ?
for the low-level mechanism:
void handler(int i)	/* i is the interrupt number */
for the kl mechanism
void handler(void *p)
here, p should be a pointer to some user-defined data... Currently, it
is a pointer to an integer variable containing the irq number.

>   how to install a custom exception handler (e.g. for exc.13, GPF) while using kernel
>   library?
Currently, you have to use the lower-level call l1_exc_bind...
I think noone ever used the kl interface for exceptions, hence it is not
implemented... Of course, patches are accepted ;-)

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



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
L'interpretazione dei doni di orti, frutteti, prati e giardini nel nostro Ristoro Sunflower.
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1478&d=5-5

[Oslib-devel] various IRQ functions

[<pao...@ti...>]

Hi Juras!

here is a small file that contains a picture that shows all the relations=
hips
between the various IRQ functions in OSLib (and their relationships with
the S.Ha.R.K. Kernel)...

I posted it a few weeks ago but I think it got bounced :-(

Enjoy

PJ

PS: The image is quite big, but I can properly see it under ghostview und=
er
Linux...

__________________________________________________________________
Non sei ancora abbonato Tiscali ADSL? Peccato! 
Ti stai perdendo un sacco di vantaggi! 

Video Comunicazione, Musica, Film e tanti altri servizi gratis per te. 

Abbonati subito, risparmi fino a 343 euro!   
http://point.tiscali.it/adsl/index.shtml

[Oslib-devel] irq_bind, int_bind etc

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

Hello oslib-devel,

  What's the difference between irq_bind and l1_irq_bind ?
  what's the function's prototype which is called on an interrupt ?

  how to install a custom exception handler (e.g. for exc.13, GPF) while using kernel
  library?

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

[Oslib-devel] bugs

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

Hello oslib-devel,

  sorry, i found the error in my code. $) ups $)

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

Re: [Oslib-devel] multi-tasking (ll_context) and vm86_ functions...

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

Hi Juras,

>   I suspect there's a bug when using vm86 functions together with
>   contexts.
>   When the vm86_callBIOS function is called from the main program
>   it is ok. But when it is called from a context (no multitasking
>   switch by timer is
>   done, but simply the code calling vm86 BIOS is in the thread body).
> 
>   ll_context_to in the main program, and vm86_callBIOS in the thread body that's all.
>   When vm86_callBIOS from the main program (default task) it works fine!
> 
>   I see: Exception 5, Unvalid opcode.
Sorry, I am a little bit confused by your description... Can you post a
simple example that triggers the bug?

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



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Prova la convenienza di eBay: migliaia di articoli a prezzi senza confronto.

Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=529&d=4-5

[Oslib-devel] multi-tasking (ll_context) and vm86_ functions...

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

Hello oslib-devel,

  I suspect there's a bug when using vm86 functions together with
  contexts.
  When the vm86_callBIOS function is called from the main program
  it is ok. But when it is called from a context (no multitasking
  switch by timer is
  done, but simply the code calling vm86 BIOS is in the thread body).

  ll_context_to in the main program, and vm86_callBIOS in the thread body that's all.
  When vm86_callBIOS from the main program (default task) it works fine!

  I see: Exception 5, Unvalid opcode.

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

[Oslib-devel] l1_ and ll_

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

Hello oslib-devel,

  Using IDT_place while using timer events may cause an error.
  I fixed this by using l1_int_bind instead of IDT_place.

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

Re: Re[2]: [Oslib-devel] [Fwd: Re: OSLib, my os (SD-32 stormdos)]

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

> By the way, I want to warn once more that under VMWare
> (trial) I experienced problems running OSLib-based programmes... but with Bochs it's all ok.

I never tried with VMware.... I currently use a VMware 3.2 (registered)
version... I'll try when I'll have a few minutes...

> >> > The "standard solution" to your problem would be to use this variable
> >> > (since the killer executes in the context of the thread that is
> >> > terminating...).
> well, because I use the same functions for user threads, i.e. the
> threads created in user applications. So it would be convenient to
> have a thread ID as a parameter.

We can say "a parameter in general"... If you look at what happens in
the OS standards, POSIX Pthreads pass a void* as parameter, and they
give access to the thread ID using pthread_t... and if we think at a
portable application, pthread_t is an opaque type, and we cannot use it
to ask questions like "is this the thread 2 or the thread 3?"

> But now I think that we do not need to modify OSLib,
> I'll solve the problem another way. Let's not introduce any
> uncompatibility.

I mean, it's not incompatibility, because shark simply do not use the
killer function at all... simply my feeling is that forcing a thread to
receive its thread ID only by parameter do not solve the problem
(because it is unlikely that you'll pass the thread ID to all the
library functions that maybe will need it... and adding a function that
returns the pthread id of a task makes unuseful to pass it as
parameter...

[...]
> It's also a possible solution, thanks.

It's the one we currently use simply because I needed to:
- be able to kill a task if it has been asynchronously cancelled before
being executed
- be able to deliver pending signals when the task is scheduled the
first time
- know the return value of a thread, and basically the killer function
cannot read it (that's why I do not use it; an eventual parameter to
that function should be pushed on the stack before the killer return
value, so it doesn't work for the return value :-( )

> Now I decided to do the following: to use a default kernel-build-in
> killer function which calls an application defined killer body, and then
> using the global variable indicating the active task the function destroys the task
> with the CONTEXT...

Ok!!!

> Thanks for reply!

You're welcome!!!

PJ

-- 
Paolo Gai <pao...@ti...>

Re: [Oslib-devel] [Fwd: Re: OSLib, my os (SD-32 stormdos)]

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

Hi Luca! Hi Jury!!!

I hope you had a nice Easter 9unfortunately here in Italy the weather
has been really bad :-( )

Btw, I'm really happy that Jury has done something working with OSLib
:-)))

> > >   I use a table of 'process entries', i.e. an array of structures
> > >   describing a process: base, size, stack, stack_size, CONTEXT, flags. The
> > >   flags inform whether a process is active, whether this entry is
> > >   occupied/valid and a kind of process: child/thread or
> > >   parent/program. So inside my system I use PROCESS_IDs which
> > >   reference into that table of processes, i.e. not CONTEXTs.
> > Ok... This is a fairly standard solution: shark is also using something
> > similar.

Yes... really the same thing!!! ;-)

> > >   As I use
> > >   context_create/delete I use a default killer procedure which uses my
> > >   own delete_process function but (!) the killer function gots no
> > >   parameters (opposite to the thread body) so I have to find my
> > >   PROCESS_ID by looking through the table of processes for
> > >   entry[i].ctx==ll_context_from().
> > Generally, a kernel has some variable storing the ID (in your case, an
> > integer indicating the PROCESS_ID) of the executing thread/task. This is
> > used by the scheduler (or by some other kernel subsystem) to perform
> > accounting, and is set by the scheduler when a context switch happens.
> > The "standard solution" to your problem would be to use this variable
> > (since the killer executes in the context of the thread that is
> > terminating...).
> > 
> > > The only thing I ask to add into OSLib
> > >   is a function ll_context_create() with a support for killer routine
> > >   with a parameter, so I can pass a process's ID as a parameter and
> > >   simply do:
> > Ok, if you really want it (i.e., if you cannnot or don't want to use the
> > "current task" variable), I have no objection to such modification...
> > The only problem is that I have not much time to implement it right now
> > (I am busy with my job, and I'll be out of town for about 3 or 4 days in
> > the next week). Hence, I could do it only after the 1st of may. In the
> > meanwhile, if you want to provide a patch (it should not be that
> > difficult: I think that pushing the parameter on the task stack when
> > build it in ll_context_create would be enough), you are welcome.

What I think is:

the parameter in the context_create existed because we initially wanted
the possibility to create different threads that used the same thread
body with a different argument, as done for example in POSIX. 

In the first versions of Hartik, the thread body  was simply given into
the task_create together with its parameter. these informations were
then directly passed to ll_context_create(), so the parameter we passed
in the ll_contect_create was the same parameter passed to the thread.

In Hartik the killer function had no parameter because in any case the
kernel knows which is the task that is running at a given time, using a
global variable.

If I understood well, Juras is using the parameter to pass the
thread_ID, and then he maybe find eventual parameters into the thread
descriptor using that ID... then he would like to have the same
parameter in the killer function to kill the task... in that case, maybe
you do not need a killer function at all, just because you can use the
first function that has been called...

This is the code that is currently passed as body to the
ll_context_create (exec_shadow is the current running task; the abort
function is not used at all...

void task_create_stub(void *arg)
{
  void *ret;
  kern_after_dispatch();  // check for asynchronous cancellation and
signal delivering

  ret = proc_table[exec_shadow].body(arg); // the call to the -real-
body

  kern_cli();
  task_makefree(ret);  // internally calls ll_context_delete
  ll_context_to(proc_table[exec_shadow].context);
}

At the end, I think that Juras proposal can be replaced without too much
effort with a global variable, also saving some ram space (you need an
initial push for every context, that is 4 bytes for every context (*),
whereas in the other case you need only one global variable to store the
executing task, that is maybe also needed when the kernel becomes a
little more complex).

(*)btw, who removes it from the stack if the killer function does not
return (as it should)?

Juras, what do you think about using a global variable to store the
executing task? (I did not received the whole thred you had with Luca)

bye

PJ

PS: I passed the g++ patch to Michael and Giacomo that are currently
working on that...

-- 
-----------------------------------------------------------------------
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] oslib and c++

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

Hi all, 

during my lunch break I committed some fixes, that should permit to
compile oslib programs with g++... Paolo, can you check if this solves
your problem? 
http://sourceforge.net/tracker/index.php?func=detail&aid=704866&group_id=14468&atid=114468

If yes, I'll close the bug. 

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



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
La lavatrice ti ha abbandonato? Cerca chi ti serve su QxService e potrai vincere un Nec e606 UMTS! Clicca qui!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1412&d=22-4

[Oslib-devel] [Fwd: Re: OSLib, my os (SD-32 stormdos)]

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

Jury,
I sent an answer to you, but it bounced...


Others (mainly Paolo),
are you ok with the interface change proposed by Jury (adding a
killer_param parameter to ll_context_create)?

			Luca
-----Forwarded Message-----

> From: Luca Abeni <luc...@em...>
> To: Jury Benesz <yb...@tu...>
> Subject: Re: OSLib, my os (SD-32 stormdos)
> Date: 22 Apr 2003 16:03:19 +0100
> 
> Hi Jury!!!
> 
> >   I'm glad to infrom you that my own OS based on OSLib and partially
> >   freedos-32 is going to work! ;)
> Cool!!!
>  
> >   I use a table of 'process entries', i.e. an array of structures
> >   describing a process: base, size, stack, stack_size, CONTEXT, flags. The
> >   flags inform whether a process is active, whether this entry is
> >   occupied/valid and a kind of process: child/thread or
> >   parent/program. So inside my system I use PROCESS_IDs which
> >   reference into that table of processes, i.e. not CONTEXTs.
> Ok... This is a fairly standard solution: shark is also using something
> similar.
> 
> >   As I use
> >   context_create/delete I use a default killer procedure which uses my
> >   own delete_process function but (!) the killer function gots no
> >   parameters (opposite to the thread body) so I have to find my
> >   PROCESS_ID by looking through the table of processes for
> >   entry[i].ctx==ll_context_from().
> Generally, a kernel has some variable storing the ID (in your case, an
> integer indicating the PROCESS_ID) of the executing thread/task. This is
> used by the scheduler (or by some other kernel subsystem) to perform
> accounting, and is set by the scheduler when a context switch happens.
> The "standard solution" to your problem would be to use this variable
> (since the killer executes in the context of the thread that is
> terminating...).
> 
> > The only thing I ask to add into OSLib
> >   is a function ll_context_create() with a support for killer routine
> >   with a parameter, so I can pass a process's ID as a parameter and
> >   simply do:
> Ok, if you really want it (i.e., if you cannnot or don't want to use the
> "current task" variable), I have no objection to such modification...
> The only problem is that I have not much time to implement it right now
> (I am busy with my job, and I'll be out of town for about 3 or 4 days in
> the next week). Hence, I could do it only after the 1st of may. In the
> meanwhile, if you want to provide a patch (it should not be that
> difficult: I think that pushing the parameter on the task stack when
> build it in ll_context_create would be enough), you are welcome.
> 
> 				Luca
> -- 
> _____________________________________________________________________________
> Copy this in your signature, if you think it is important:
>                                N O    W A R ! ! !
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Vuoi un notebook potente, funzionale ideale per il lavoro?
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=763&d=22-4

[Oslib-devel] Re: X 5.0 & X 5.2 problems ... updated

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

Hi,

I was wrong...

it was X 5.0 (initial checkout from the CVS) that blocked, and X 5.2
(latest checkout from the CVS) that worked ok...

excuse me for this mess...

bye

PJ

On Tue, 2003-04-15 at 12:32, Paolo Gai wrote:
> Hi guys,
> 
> Giacomo has compiled X using the sources I put on my homepage (that is a
> checkout of the eXtender source code on the sourceforge CVS). 
> 
> - X 5.2 as distributed by Luca resets the PC :-(
> 
> - X 5.0 (that is, the CVS tree with initial tag initial_revision) WORKS
> WITH THE NEW OSLIB with and without debug printings. I attach the
> compiled version together with this mail. NOTE: that version PRINTS
> "eXtender version 5.2"!!!
> 
> - X 5.2  (that is, the latest CVS Checkout) DO NOT WORK, and when it
> starts it says "Lock Blocked"
> 
> We are thinking it may be a problem related to the compiled version Luca
> put on the web...
> 
> We currently compiled it using TC 1.0 and the NASM version available in
> the nasm website under the name nsm09836.zip
> 
> bye
> 
> PJ
-- 
Paolo Gai <pao...@ti...>
Scuola S. Anna

Re: [Oslib-devel] Two patches

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

Hi Luca...

(I'm putting a bug also into the shark bugzilla, maybe someone has time
to work on it...)

I tried the cygwin patch on a clean shark/oslib checkout with the
following results:

shark does not compile
oslib compiles :-)

I executed it on an old Pentium 133 with X 5.2

- on Win 98 the system hangs, X says:
-----------------
Multiboot Loading
Getting area of size 2178208 (0x213ca0)
Got: 111000
-----------------

- on a Freedos bootdisk after 
Got: 111000
it says 

0 0 0 0.... 0 0x0
0x0 Called Alloca(0)

on vmdemo.xtn

 and on scheddemo.xtn it says:

ff 7 0 90 32 0 ff 7 0 a0 32 0 0 0 0 0 0x900007ff
0x900007ff Called Alloca(0)
Error! [...message for one-shot]!!!Lowlevel started...
All Threads created...
Thread MAIN restartin'

both the demos blocks both in Windows 98 and in FreeDOS and, and I have
to reboot the PC :-(

bye

PJ

On Thu, 2003-04-10 at 16:53, Luca Abeni wrote:
> Hi guys,
> 
> there are two patches in the oslib patch manager on sf:
> http://sourceforge.net/tracker/?group_id=14468&atid=314468
> 
> - The first one should fix some compilation problems experienced with
> gcc 2.96 and 3.2 (see
>
http://sourceforge.net/tracker/index.php?func=detail&aid=703505&group_id=14468&atid=114468). It seems to work fine, but needs more testing, with different compilers (I would like some feedback before committing it to the cvs).
> - The second one is just an input for people willing to compile oslib
> applications with cygwin or mingw... The examples compile, but they do
> not seem to work correctly. If someone manages to fix it so that the
> examples compile and actually execute without problems, I'll commit
the
> correct version.
> 
>                               Thanks,
>                                       Luca
-- 
Paolo Gai <pao...@ti...>
Scuola S. Anna

[Oslib-devel] Two patches

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

Hi guys,

there are two patches in the oslib patch manager on sf:
http://sourceforge.net/tracker/?group_id=14468&atid=314468

- The first one should fix some compilation problems experienced with
gcc 2.96 and 3.2 (see
http://sourceforge.net/tracker/index.php?func=detail&aid=703505&group_id=14468&atid=114468). It seems to work fine, but needs more testing, with different compilers (I would like some feedback before committing it to the cvs).
- The second one is just an input for people willing to compile oslib
applications with cygwin or mingw... The examples compile, but they do
not seem to work correctly. If someone manages to fix it so that the
examples compile and actually execute without problems, I'll commit the
correct version.

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



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

Sponsor:
Vestiti da campione! Abbigliamento tecnico e Accessori giusti per lo Sport del cuore
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1079&d=10-4

Re: [Oslib-devel] Argc & argv elaboration

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

Ok,

I just committed some changes to the cvs... Have a look, and let me know
if they are ok. Since I have not too much time, I only did a limited
testing, but the examples seem to still build and work correctly (at
least in bochs).

> Btw, we found another bug on the irq handling related to the slave
> interrupt controller... Giacomo or Michael will send the patch on the
> mailing list during this morning!!!

Ok, I'll commit the patch as soon as I receive it.

			Luca

[Oslib-devel] Some documentation

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

Hi,

Yesterday we did a little bit of reverse engineering of the interrupt
handling in OsLib to find a nasty bug. At the end, we got a picture of
how the interrupts are handled in OSLib (and in S.Ha.R.K.), so I decided
to design a picture with Dia that outlines the main functions that are
related to IRQ handling.

I think that this picture may be useful to other people, so I decided to
put it in attachment...

Enjoy,

PJ

-- 
-----------------------------------------------------------------------
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
------------------------------------------------------------------------

Re: [Oslib-devel] Error with building the examples

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

Hi Carsten,

 
> I tried to build the examples on win32:
> 
> The libs have been well. Everything can be found in
> "lib", but with the examples I have some problems...
> 
> I am compiling and linking with the win32-gcc MingW32.
The problem is that mingw32 is currently not supported. We support the
linux gcc (producing ELF files) and DJGPP (producing multiboot coff
files).
You probably copied dos.mk in config.mk, so the build system is
configured to use DJGPP, and is trying to generate a coff file, that is
not supported by the mingw32 linker.

Simple solution: install DJGPP (it works under windows, too) from
http://www.delorie.com.

More complex solution: generate a config.mk file that can be used with
mingw32. Obviously, you have to change the -oformat coff-go32 option,
and probably you have to change the os.x linker script. I remember that
I was able to compile the examples with cygwin ont time, and that there
was some weird problem related to the main and start symbols (the
windows compiler uses different names, if I remember well).

I'll try to have a look at the problem, and to generate a win.mk file in
the next days.

			Luca

Re: [Oslib-devel] Argc & argv elaboration

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

> > Yes!!!... in that way, we should be able to customize all the startup
> > phase...
> Ok, I'll do it, and commit it during my lunch break

Thank you, Luca!!! :-)))))

> I would go for the third solution: move _startup() (and all the variable
> referenced by it) in a new object file. The linker is smart enough to
> avoid linking that file if there is no reference to _startup().

Perfect!!!

Btw, we found another bug on the irq handling related to the slave
interrupt controller... Giacomo or Michael will send the patch on the
mailing list during this morning!!!

bye

PJ

Re: [Oslib-devel] Argc & argv elaboration

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

Hi Paolo,
On Thu, 2003-03-20 at 08:15, Paolo Gai wrote:
> > I think the solution is to have a STARTUP macro in xo.s, instead of a
> > MAIN macro in x1.c... If you think it is ok, I'll commit a change on the
> > cvs. 
> 
> Yes!!!... in that way, we should be able to customize all the startup
> phase...
Ok, I'll do it, and commit it during my lunch break

> 
> ...and what happens to the _startup function in xlib/x1.c? ... maybe if
> a user wants a customized startup phase he do not need anymore that
> function... I think the options in this case are two:
> - not to compile xlib/x1.c
> - compile it with the _startup function "removed" through #ifdef...
I would go for the third solution: move _startup() (and all the variable
referenced by it) in a new object file. The linker is smart enough to
avoid linking that file if there is no reference to _startup().

				Luca

Re: [Oslib-devel] Argc & argv elaboration

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

> I think the solution is to have a STARTUP macro in xo.s, instead of a
> MAIN macro in x1.c... If you think it is ok, I'll commit a change on the
> cvs. 

Yes!!!... in that way, we should be able to customize all the startup
phase...

...and what happens to the _startup function in xlib/x1.c? ... maybe if
a user wants a customized startup phase he do not need anymore that
function... I think the options in this case are two:
- not to compile xlib/x1.c
- compile it with the _startup function "removed" through #ifdef...

> Regarding the original (argv) problem, I'd prefer to commit something
> like this, if it works ok for you: 
[...]

I think it works and it is fine. In our case (shark), anyway, this code
will not be used since we'll maybe simply customize the _startup...

bye

PJ

[Oslib-devel] Error with building the examples

[Kniffo v. S. <kn...@ya...>]

Hello everyone, this is my first posting here :)

I tried to build the examples on win32:

The libs have been well. Everything can be found in
"lib", but with the examples I have some problems...

I am compiling and linking with the win32-gcc MingW32.

If I try to compile and link them, just typing "make"
in examples, it spits out these error messages:

-snip-
gcc -Wall -O -finline-functions -fno-builtin -nostdinc
-D__GNU__ -I.. -c mbdemo.c
ld -T ../mk/os.x -Bstatic -Ttext 0x320000 -oformat
coff-go32 -s -nostartfiles -n
ostdlib -L../lib/ ../lib/x0.o mbdemo.o --start-group
-lhc -lhm -lhx -lkl -lcons
--end-group -o mbdemo.xtn
ld: target coff-go32 not found
make: *** [mbdemo.xtn] Error 1
rm mbdemo.o
-snip-

Well, do you see the problem? I looked into the
helpfiles to ld and looked up the usage of the win32
ld and there are no problems in creating and using
custom build-scripts... so I dont know the problem..

Can you help me out ppl??

Thanx,
Carsten

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

[Oslib-devel] Some news

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

Hi all,

I just committed two new examples:
	- readdemo.c ---> tests DOS_fopen(), DOS_fread() & friends
	- pitsched.c ---> shows how to implement a scheduler without
	  using events

Both the examples seem to be working well.
I also added a check in DOS_init(), so that it fails if the program is
not ran through the eXtender.

Finally, I changed something in xlib/exc.s (this is needed by
pitsched.xtn if the timer handler is installed by using l1_irq_bind()
instead of irq_bind()). Please check if everything is still working
ok... If you see problems, try to recompile with -D__LATE_EOI__.

				Luca

Re: [Oslib-devel] Argc & argv elaboration

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

Hi, 

On Wed, 2003-03-19 at 15:02, Paolo Gai wrote: 
> 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...
I think the solution is to have a STARTUP macro in xo.s, instead of a
MAIN macro in x1.c... If you think it is ok, I'll commit a change on the
cvs. 

Regarding the original (argv) problem, I'd prefer to commit something
like this, if it works ok for you: 

Index: xlib/x1.c 
=================================================================== 
RCS file: /cvsroot/oslib/oslib/xlib/x1.c,v 
retrieving revision 1.4 
diff -r1.4 x1.c 
77a78,79 
> #define MAX_ARG_SIZE 1024 
> static char private_args[MAX_ARG_SIZE]; 
102d103 
<   char *cmdline = (char *)(mbi->cmdline); 
111,115c112,118 
<     while (cmdline[i] != 0) { 
<       _argv[_argc] = &(cmdline[i]); 
<       while (cmdline[i] != ' ' && cmdline[i] != 0) i++; 
<       if (cmdline[i] == ' ') { 
< cmdline[i] = 0; i++; _argc++; 
--- 
>     memcpy(private_args, (char *)mbi->cmdline, MAX_ARG_SIZE); 
>     private_args[MAX_ARG_SIZE - 1] = 0; 
>     while (private_args[i] != 0) { 
>       _argv[_argc] = &(private_args[i]); 
>       while (private_args[i] != ' ' && private_args[i] != 0) i++; 
>       if (private_args[i] == ' ') { 
> private_args[i] = 0; i++; _argc++; 

				Luca