osso-develop — OSSO Developers Mailing list

Re: [Osso-develop] 9P protocol

[Marco P. <ma...@cl...>]

It could be very interesting!

I'll read some documentation as soon as possible.



Il giorno 05/gen/11, alle ore 17:56, Alessandro Iurlano ha scritto:

> This could be a nice protocol to implement in OSSO.
> What do you think?
>
> http://en.wikipedia.org/wiki/9P
>
> :)
>
> ---------------------------------------------------------------------- 
> --------
> Learn how Oracle Real Application Clusters (RAC) One Node allows  
> customers
> to consolidate database storage, standardize their database  
> environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC  
> database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Osso-develop mailing list
> Oss...@li...
> https://lists.sourceforge.net/lists/listinfo/osso-develop

[Osso-develop] 9P protocol

[Alessandro I. <ale...@gm...>]

This could be a nice protocol to implement in OSSO.
What do you think?

http://en.wikipedia.org/wiki/9P

:)

[Osso-develop] OSSO: bug di fork e gcc>4 - progressi

[Alessandro I. <ale...@gm...>]

Ciao!
Ho scoperto che e' il file kernel/syscall.o che se viene generato con
gcc-3.4 funziona tutto, ma se viene generato con gcc 4 la fork() fa bombare
osso. Il perchè è ancora un mistero.
Il file presenta poca roba strana... e la cosa ancora piu' strana e' che
solo la fork si rompe.
Suggerimenti????

Ale

[Osso-develop] Code Repository switched to Subversion

[Alessandro I. <ale...@gm...>]

Hello all.
The source code repository of the Osso project has switched from CVS to
Subversion.
You can checkout a new working dir with this command:

  svn co https://osso.svn.sourceforge.net/svnroot/osso osso

Regards,
Alessandro

[Osso-develop] Nuovi messaggi!

[Alessandro I. <ale...@gm...>]

Ciao!
Ho finalmente risolto gli ultimi bachetti dei nuovi messaggi che
sembrano funzionare proprio bene!
Eccoti in dettaglio le novità:
1) OSSO si rifiuta di compilare con gcc 4 (era questo che mi dava tanti
problemi!)
2) le primitive di scambio messaggi sono completamente cambiate ma ho
tenuto dei wrapper per compatibilità con le vecchie funzioni.
3) la struttura msginfo è cambiata e un campo ha cambiato nome, da
"mittente" a "processo". Ho aggiornato tutti i riferimenti che ho
trovato in giro

Le nuove funzioni si chiamano send_message e receive_message. Si possono
ricevere tutti i messaggi oppure quelli di un certo tipo o quelli
provenienti da un certo processo o entrambe le condizioni. Il
funzionamento è questo:

int send_message(int flags,msginfo * msgi,void * MsgAddr);
flags per la send ha poco senso per ora. Il valore normale è 0. msgi è
una struttura msginfo. Vanno messi li' dentro il destinatario e la
dimensione del messaggio. MsgAddr è il buffer restituito da getbmsg come
prima. Esempio:

    ppio=getbmsg();
    sprintf(ppio,"Test msg number %d",x);
    printf("Padre : Spedisco Messaggio al processo figlio (%
d) ...\n",figlio);
    mi.dimensione=strlen(ppio);
    mi.processo=figlio;
    mi.type=x;
    if (i=send_message(0,&mi,ppio)) {
      printf("***** Send_MESSAGE !=0 (%d)\n",i);
    }
 
void * receive_message(int flags,msginfo * msgi);
qui flags ha più senso. Può essere NO_BLOCK che dà un comportamento non
bloccante e restituisce NULL nel caso si sarebbe dovuta bloccare;
MSG_FLG_TYPE_MATCH per filtrare sul tipo del messaggio;
MSG_FLG_SENDER_MATCH per filtrare in base al mittente; o una
combinazione in or di questi tre flags.
Il valore da usare come confronto per i filtri è nella struttura
msginfo. Esempio:

      mi.processo=getppid();
      mi.type=33;
      ppio=receive_message(MSG_FLG_TYPE_MATCH|MSG_FLG_SENDER_MATCH,&mi);
      printf("Figlio : Messaggio ricevuto da %d, tipo %d
\n",mi.processo,mi.type);
      printf("Figlio : Testo del messaggio n. %d '%s'\n",x,ppio);

Che riceve solo dal padre e solo del tipo 33.
Come al solito non ho testato benissimo, ma un po' si :D

Ah, ho trovato un bug nella sintassi di initconf. Ho aggiunto un wait
per iso9660 e ho notato che la sintassi di name:iso non veniva
riconosciuta se non mettevo anche la keyword root. Ovvero 

preload driver name:iso root = iso9660 device=hdc mount=/ 
funziona

mentre
preload driver name:iso = iso9660 device=hdc mount=/ 
non funziona.

Fammi sapere!
Ciao!

[Osso-develop] Announce: new OSSO version released

[Alessandro I. <iu...@us...>]

I'm pleased to announce that OSSO version 0.0.5 is out.
This is an approssimative changelog:

 * Bugfixed serial output of boot phase and kernel
 * Added make iso target to create an iso9660 bootable image
 * Bugfixed kernel-loader.c (sometimes a loaded sector was filled by
zero)
 * Adjusted makefiles to be sensible to CC environment variable
 * Made OSSO compatible with gcc 4
 * Bugfixed and extended boot phase interactions to manage driver
dependencies
 * More Bugfixes
 * New syntax for initconf configuration file

A prebuilt bootable ISO is available to download from the homepage
http://osso.sourceforge.net or project page
http://sourceforge.net/projects/osso at the file section.

Enjoy, Alessandro

[Osso-develop] OSSO is born again and a new release approaching

[Alessandro I. <iu...@us...>]

Hello all.
This mail is just to test the osso-develop mailing list functionality
after all this time and to announce that the OSSO project is born again,
and a new release is near. Version 0.0.5 will be more stable and have
cdrom support. We want to release a bootable iso too.

Alessandro Iurlano

[Osso-develop] Page fault correction

[Stefano R. <st...@in...>]

I've corrected the insidious bug that cause random page faults in fat, mps, 
vfs or ide.

This is caused by service 2 of int 13h that don't work if, as address, is 
passed a data area that overlap a block of 0x10000 bytes.
The patch skip this problem by reading sector in another block e then copying 
it to destination area.

In case of other errors, is possibly to uncomment "SECTOR_VERIFY" definition 
in "src/boot/fat.c" to check if sector are read correctly: is very slow but 
useful!

Bye,

Stefano Rosellini

   E-MAIL: st...@so...

Re: [Osso-develop] hi:Asheesh

[Alessandro I. <iu...@cl...>]

> Hi Alessandro,
>
> I would love to contribute for the OSSO project. Let me tell you  my
> skill set - I know C/C++..I am not very good at x86 asm. I have been
> learning about OS development since about last 4/5 months (mainly
> through news groups).

OK. Good.
> I have a 'spare' P2 machine with 4gb hardisk/ 64mb ram/ CD/floppy/NIC
> .which I can use for OSSO testing  :-)...

great :)

> I think , with my state of skills ...I cannot contribute much as far as
>  OS coding is concerned...but I can certainly help you in testing &
> documentation. I think this will help in my learning process a lot.

And you will help us too :)

> Since I work ( have a job), I can only work on weekends...so I can give
> 10 hrs a week ( of course I wont ask for money ;->>).

don't worry about that, our free time is poor too :(
For the money: great! we won't ask too :)

>
> Let me know your opinion and what the other team members feel.
>

My opinion is that your help will be appreciated.
These are the things I though you could do:

for documentation:

Document interfaces between the Module Pid Server (mps) and drivers. For
them there already is a prototype and working code, but they are not a
definitive version.
Create some documents to let people know how to run and test OSSO and how
to write programs for OSSO.
other things may follow as other team members (Stefano and Marco) may add
new ideas.

for coding:

Test programs of every kind should be created. Fantasy is appreciated.
also, the programs that are actually part of the test dir should be
assigned the rank of system utilities. More of those system utilities are
needed.

Drivers writer and/or debugger are always the thing that an os needs more.
Here no asm programming is required. If you know or want to learn how to
program some device, that would be the thing we'd appreciate most. If you
feel you do not have the knowledge, I will help you, cause I've become
really skilled in hardware programming. A test hardware of what you are
writing a driver for is needed.

The C library (or libOSSO.so, as I've called it) also need work. The best
thing would be a study about porting the gnu libc, but that is really
difficult. Alternatively, the library has to be filled with an
implementation of the functions present in the glibc that are general,
like string functions.

Kernel programming is currently stopped because we are replanning its
major subsystem, starting from memory management. Compatibility with
current programs will be kept, of course.

These are the things that actually come into my mind. If none of them is
of your interest, I could find something else.

The other members agree on those things, but could eventually provide some
other advice.

I will provide any help and knowledge you might need to accomplish the
task you choose.
Help to our project is allowed in form of patches to the CVS snapshot. You
need to create a patch with diff programs and send it to me at iurlano at
users.sourceforge.net and I will test it and eventually include it in the
code repository. Documentation that doesn't fit into the
OSSO/Documentation directory of the repository should be send in a usable
formate (possibly not proprietary) and I will eventually include into the
sourceforge project doc's page.

> In the meantime, I had following questions...
> 1. where can I find more help on BCC? like '-Ms' & '-ansi' option

You can just execute man bcc. If you do not have this manpage in your
system, I can send you that.

> 2. I wanted to know what is the executable format that is generate? I
> think it is a.out- I saw the bootloader.nasm code and there is a
> '%ifdef BCCLOADER '  and I cannot understand what is done within this
> %ifdef and %endif part...particularly, where does it jump to  if
> BCCLOADER is defined ?


Argh! That was an hack I made with Stefano quite a long time ago, and I
can't remember right... Loader is a linux-8086 executable and that is the
interpretation of the file header and it jumps to the entry point of the
bcc generated file. I don't remember where I found that info... Sorry.



> 3. is there a tool like objdump for 16bit code? >

objdump86 :)

> Thanks a lot
> Best regards
> Asheesh
>


Hope to hear you soon,
			Alessandro

[Osso-develop] hi:Asheesh

[aa <uc...@ya...>]

Hi Alessandro,

I would love to contribute for the OSSO project. Let me tell you  my
skill set - I know C/C++..I am not very good at x86 asm. I have been
learning about OS development since about last 4/5 months (mainly
through news groups).
I have a 'spare' P2 machine with 4gb hardisk/ 64mb ram/ CD/floppy/NIC
.which I can use for OSSO testing  :-)...
I think , with my state of skills ...I cannot contribute much as far as
 OS coding is concerned...but I can certainly help you in testing &
documentation. I think this will help in my learning process a lot.
Since I work ( have a job), I can only work on weekends...so I can give
10 hrs a week ( of course I wont ask for money ;->>).

Let me know your opinion and what the other team members feel.

In the meantime, I had following questions...
1. where can I find more help on BCC? like '-Ms' & '-ansi' option
2. I wanted to know what is the executable format that is generate? I
think it is a.out- I saw the bootloader.nasm code and there is a
'%ifdef BCCLOADER '  and I cannot understand what is done within this
%ifdef and %endif part...particularly, where does it jump to  if
BCCLOADER is defined ?
3. is there a tool like objdump for 16bit code?

Thanks a lot
Best regards
Asheesh

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: [Osso-develop] Crash with plex86 and FAT

[iurlano <iu...@cy...>]

> Hi

Hello!
> 
> I'm trying to run OSSO with plex86 (from woody) and it crash when loading
> fat driver. If I don't load fat driver it runs, but obviously it stops after
> loading ide driver. 
> Is someone using plex86?

No. I'm testing OSSO using bochs and my other computer.

> I'll install bochs and I'll try with it, but I'm not sure that it work.
>  
>                                               Bye, Aitor

Which version of the binutils package are you using?

I've got lot of problems using the binutils in sid since last November to
compile OSSO. I've found that the executables that it generates are not
correctly loaded and relocated and crash with a segfault just when
starting. Now I use version 2.11.2 of the binutils and seems to work.

Bye, Ale

[Osso-develop] Crash with plex86 and FAT

[Eismann <ei...@wa...>]

Hi

I'm trying to run OSSO with plex86 (from woody) and it crash when loading
fat driver. If I don't load fat driver it runs, but obviously it stops after
loading ide driver. 
Is someone using plex86?
I'll install bochs and I'll try with it, but I'm not sure that it work.
 
                                              Bye, Aitor

[Osso-develop] Bug reports

[Alessandro I. <iu...@cl...>]

I've started using sourceforge bug reporting system...

Have a look!

There is an access trough the osso home page

Bye bye

[Osso-develop] A new driver and thoughs about a new release

[Alessandro I. <iu...@cl...>]

Hi all!

I've added a very simple driver, the loopback device. It implements the
same functionality (well, it tries) as the mount -oloop command in linux.

It is in drivers/loopback.c
I've updated the configuration program too.
In the Documentation directory I've added the file LOOPBACK.txt which
contains some info on its usage.

I've tested it using a fat16 image file. It seems to work perfectly.
:)

Ah, just another new feature. I've managed to have IDE read from a cdrom.
I've only been able to test it on Bochs, and it is quite a hack. But it
seems to work and I've read a FAT image from hdb (the cdrom in bochs) and
mounted it on /disk2.


I've realized that the stable kernel is quite far away but the current CVS
snapshot has quite some new features more than the 0.0.4 version.
Do you think I should release a 0.0.5 version? If people don't see
changes, will not come back to the site.
Tell your opinion about it, please.


Bye bye, Alex

Re: [Osso-develop] memory interface

[Eismann <ei...@wa...>]

> Memory managing and mapping strategy have to change drastically, to 
> reorganize and speedup things. The current version has only to work. 
> Well, it's some time that I don't think seriously at memory managing, so I'll 
> reorder my ideas and will explain you precisely (...) what I think in one 
> other messages.
> 
> To make you thinking >:-) :

I like it :-)


> How do you think to implement swap?
Really I don't know. I don't know how should be the communication with the HD driver.
I'll think about it.

Bye, bye

         Aiitor

Re: [Osso-develop] memory interface

[Marco P. <mar...@ti...>]

> Maybe you haven't understood me, or I haven't understood you.
Ehm... each other?

> > Well, not really the kernel (in the sense that is not centralized).
>
> Yes, I'm talking about inerface between kernel and mem manager. The two
> things are the kernel. With mem manager I refer to kernel mem manager
> subsistem, and with kernel to the rest of the kernel.
I think we are thinking the same things (more things I cannot... :-)

> > > I think it would be better (more clear) if the kernel touches this
> > > things the minimum possible.
>
> Example. Now in getbmsg() from messages.c, it asks for pages and it maps
> the pages to process linear memory. I'm saying to do this into memory
> manager (that it is into the kernel too).
YES!  OOOHHH! We talk and doesn't understand each other (parlamm' e nun ce 
capimm'...)  

> The process requests for memory with mallosso(), and mallosso() requests
> for pages to the physical memory manager?. This is what I was thinking...
Yes, exactly. The point is that each process that uses memory allocation
(with mallosso(), getmesg(), or every other functions, do the mapping in his 
logical space itself, without owning any global lock, like a lib function 
(but under the control of kernel). The only thing that is centralized is 
taking pages, but we could do this quite fast (I think), probably in parallel 
if we really want.

> Excuse me if I haven't understood you and I 've confused more the things.
No, excuse me. I was thinking that you liked a SEPARATE PROCESS doing memory  
managing (for other processes). There are some OSes that are doing this 
(I think HURD too).

Memory managing and mapping strategy have to change drastically, to 
reorganize and speedup things. The current version has only to work. 
Well, it's some time that I don't think seriously at memory managing, so I'll 
reorder my ideas and will explain you precisely (...) what I think in one 
other messages.

To make you thinking >:-) :
How do you think to implement swap?

Bye,
Marco.

Re: [Osso-develop] memory interface

[Eismann <ei...@wa...>]

On Wed, 27 Feb 2002 09:46:06 +0100 (CET)
Marco Peccianti <pec...@cl...> wrote:



Maybe you haven't understood me, or I haven't understood you.

> > What about logical memory manager functions?
> > And, will the kernel manage page directories and tables like now in message
> > functions, create process functions and others?
> 
> Well, not really the kernel (in the sense that is not centralized).

Yes, I'm talking about inerface between kernel and mem manager. The two things are 
the kernel. With mem manager I refer to kernel mem manager subsistem, and with
kernel to the rest of the kernel.


> > I think it would be better (more clear) if the kernel touches this things
> > the minimum possible.

Example. Now in getbmsg() from messages.c, it asks for pages and it maps the pages
to process linear memory. I'm saying to do this into memory manager (that it is into the kernel too).


> [Process: I need 30 pages]
> <Kernel: Take them!>
> 
> Obiviously this is serialized, cause only one process a time (tricks
> excluded) can use the data structures describing global memory. It handles
> only pages, to make it as fast as possible.
> It's interface is a kernel function, called internally.
> 
> 2) Logical mapper:
> It maps the pages obtained before where the process needs, and use it for
> program starting, heap, messages and so on.
> Obiviously at this level there are no process interaction, so things can
> be done in parallel.
> It's interface is made by getmesg(), or Mallosso(), or everything needs to
> map memory onto process space.

The process requests for memory with mallosso(), and mallosso() requests
for pages to the physical memory manager?. This is what I was thinking...


Excuse me if I haven't understood you and I 've confused more the things.

Aitor

[Osso-develop] Some news

[Alessandro I. <iu...@cl...>]

Hi everybody!!

I've just updated the website by adding the faq section. Comments and
suggestione are welcome as always. But, please _tell_ me something.

I've also added some files into the libOSSO. I've added the atoi() and
strtol() functions.

Bye, Ale

Re: [Osso-develop] memory interface

[Marco P. <pec...@cl...>]

> From: Eismann <ei...@wa...>
> To: OSSO developer mailing list <oss...@li...>
> Subject: [Osso-develop] memory interface
>
> Hi all!
Hi!
Excuse me for the late reply,
I thought Ale replied to you, and he was thinking the same...

> Returning with the mem management topic.
Well well

> Any idea about the interface functions?
About the same...

> The physicall memory manager has functions like getpage and freepage...
yes.

> What about logical memory manager functions?
> And, will the kernel manage page directories and tables like now in message
> functions, create process functions and others?

Well, not really the kernel (in the sense that is not centralized).

My idea is a three level memory handler:

1) Page handler (serialized):
This level handles requests of pages, like

[Process: I need 30 pages]
<Kernel: Take them!>

Obiviously this is serialized, cause only one process a time (tricks
excluded) can use the data structures describing global memory. It handles
only pages, to make it as fast as possible.
It's interface is a kernel function, called internally.

2) Logical mapper:
It maps the pages obtained before where the process needs, and use it for
program starting, heap, messages and so on.
Obiviously at this level there are no process interaction, so things can
be done in parallel.
It's interface is made by getmesg(), or Mallosso(), or everything needs to
map memory onto process space.

These two levels are built in the kernel.

3) Malloc functions:
Done in the library, at user level. It makes the space obtained from the
logical level available to the process.
This is only the last ring of the chain, but obiviously it does not
concern kernel or os.

> I think it would be better (more clear) if the kernel touches this things
> the minimum possible.
Let's talk about it!
This was my idea, and I think it has some advantages:

- Kernel can do the things that is supposed to do (Starting process,
message passing) and heap handling without external interactions.
- It (may) be fast, cause the serialization points are reduced to the very
  minimum (and can be optimized in some way)
- Interactions between kernel and processes (that i really DONT KNOW HOW
  TO IMPLEMENT!!!) is needed only for swap.

I know that you like a different approach, by a process handling memory
request. Would you please explain me why and how you think so, the
advantages it has, and so on?
I like to have a global point of view and to think (and know) about
alternatives before making decisions and start coding, so your opinions
and ideas are very appreciated! Maybe we will implement your ideas...
(but you have to explain them :-)


Bye, Marco

[Osso-develop] memory interface

[Eismann <ei...@wa...>]

Hi all!

Returning with the mem management topic.
Any idea about the interface functions?
The physicall memory manager has functions like getpage and freepage...
What about logical memory manager functions?
And, will the kernel manage page directories and tables like now in message functions, 
create process functions and others?
I think it would be better (more clear) if the kernel touches this things the minimum possible.


Bye
   Aitor.

[Osso-develop] Second stage of boot is finally complete.

[Stefano R. <st...@in...>]

Hi to all,

I finished to rewrite the new boot second stage.
These are are the news (see new INITCONF for reference):

1. Now ELF kernel is supported. I added a new instruction called 'kernel' 
that must be used to load kernel (ELF or not): it can automatically 
distinguish between raw and ELF formats.

2. For each type of segments (boot and preload) can now be specified more 
intervals instead that only one. This segments can overflow each other: 
program joins or separates them automatically. You can also share an interval 
between boot and preload.
When a module must be loaded, a segments interval of required type is 
searched for. If no segments are found, loader try to find two consecutive 
intervals, one of required type and the other shared. If no segments are 
found it try to get a shared interval, else give an error of not available 
memory for load.
Loader, also, try to reserve used segments intervals (i.e. INITCONF area, 
loader area, the general parameters address area and so on...), but there's 
still memory areas used but not automatically reserved.

Bye,

Stefano Rosellini

   E-MAIL: st...@in...
HOME PAGE: web.tiscali.it/stefano_rosellini

[Osso-develop] Dynamic linker problem

[Alessandro I. <iu...@cl...>]

Hi All.

I've got a lot of problem in running OSSO recently. Whenever and in any
way I compiled OSSO, each module which needs dynamic relocation generates
a general protection fault. After a lot of study, I've come to the
conclusion that the problem resides in the ELF data generated by my gcc
compiler, which I have updated to a newer version. The dynamic linker code
in ld.c does not correctly relocates those executables.

This is why I am not being able to test OSSO till I resolve this problem.

Any ideas?

Bye, Alex

[Osso-develop] ELF kernel seems to work!!!!!

[Stefano R. <st...@in...>]

I make ELF kernel loading run!!!

Module segments management has still to be implemented: we must discuss about 
memory segments organization!

PS:
Ale, input/output from shell is very slow (probably since you added idle.c).
In addition after a variable number of seconds since the system is on it 
gives me this message:
"
OSSO pre-0.1.0 /#> INTERRUPT: Process 5 (tid == 1) caused a Page Fault at 0x8 
: 0x1FF1124
Present=0, Read, Supervisor, Address=0xFFF00AD
"


GOOD 2002!!!


Bye,

Stefano Rosellini

   E-MAIL: st...@in...
HOME PAGE: web.tiscali.it/stefano_rosellini

Re: [Osso-develop] I will be out for a time

[Alessandro I. <iu...@cl...>]

> Hi
>
>
> The Saturday I will travel to Madrid and I'll be out for 3 weeks.
> This means no computer, no internet, no... Arggg!

Happy Holiday!

I think I will work (not surely, holiday is holiday ...:) on something
marginal.
We'll resume discussing those problems when we will be back :)

Bye all!
Ale

[Osso-develop] I will be out for a time

[Eismann <ei...@wa...>]

Hi


The Saturday I will travel to Madrid and I'll be out for 3 weeks.
This means no computer, no internet, no... Arggg!
If you have something to say, say it now or shut up forever.

Bye bye
  Aitor