osfree.org

osfadmin

Site Admin

Joined: 24 Nov 2003
Posts: 60
Posted: Tue Oct 24, 2006 2:22 pm

We now discussing is MiniFSD step are required? OS/2 PPC have not such stage. Of course,
MicroFSD must be extended to support directories to make such thing.

Viking

Joined: 29 Sep 2006
Posts: 42
Location: Sweden
Posted: Sat Oct 28, 2006 8:25 am

osfadmin wrote: We now discussing is MiniFSD step are required? OS/2 PPC have not such stage. Of course, MicroFSD
must be extended to support directories to make such thing.

Why not just keep it as it is? The advantage as I see it, is that no code have to modified. Just because
there is duplicate of code between MicroFSD and MiniFSD, I don't think it's a reason to modify MicroFSD.
How should that affect your work on the bootloader/bootsector?

osfadmin

Site Admin

Joined: 24 Nov 2003
Posts: 60
Posted: Sat Oct 28, 2006 12:21 pm

Viking wrote:

osfadmin wrote: We now discussing is MiniFSD step are required? OS/2 PPC have not such stage. Of course, MicroFSD
must be extended to support directories to make such thing.

Why not just keep it as it is? The advantage as I see it, is that no code have to modified. Just because
there is duplicate of code between MicroFSD and MiniFSD, I don't think it's a reason to modify MicroFSD.
How should that affect your work on the bootloader/bootsector?

Only advantage of MiniFSD is it can work in protected mode and can read subdirectories in real mode.
But we not sure we really need to have extra real mode code only for support of directories. And not
sure current protect mode code will work with L4 kernel.

Presenting of MinoFSD will affect on boot sequemce logic. In one logic we'll need to load config.sys
drivers _before_ L4 started, in another - _after_ L4 started.

Viking

Joined: 29 Sep 2006
Posts: 42
Location: Sweden
Posted: Sun Oct 29, 2006 8:04 am

osfadmin wrote:

Viking wrote:

osfadmin wrote: We now discussing is MiniFSD step are required? OS/2 PPC have not such stage. Of course, MicroFSD
must be extended to support directories to make such thing.

Why not just keep it as it is? The advantage as I see it, is that no code have to modified. Just because
there is duplicate of code between MicroFSD and MiniFSD, I don't think it's a reason to modify MicroFSD.
How should that affect your work on the bootloader/bootsector?

Only advantage of MiniFSD is it can work in protected mode and can read subdirectories in real mode.
But we not sure we really need to have extra real mode code only for support of directories. And not
sure current protect mode code will work with L4 kernel.

Presenting of MinoFSD will affect on boot sequemce logic. In one logic we'll need to load config.sys
drivers _before_ L4 started, in another - _after_ L4 started.

Oh well, there was a lot more in that I guess. Is there a way to create a protoype to test it? What needs
to be done to make it work?

osfadmin

Site Admin

Joined: 24 Nov 2003
Posts: 60
Posted: Sun Oct 29, 2006 12:06 pm

Viking wrote:

osfadmin wrote:

Viking wrote:

Why not just keep it as it is? The advantage as I see it, is that no code have to modified. Just because
there is duplicate of code between MicroFSD and MiniFSD, I don't think it's a reason to modify MicroFSD.
How should that affect your work on the bootloader/bootsector?

Only advantage of MiniFSD is it can work in protected mode and can read subdirectories in real mode.
But we not sure we really need to have extra real mode code only for support of directories. And not
sure current protect mode code will work with L4 kernel.

Presenting of MinoFSD will affect on boot sequemce logic. In one logic we'll need to load config.sys
drivers _before_ L4 started, in another - _after_ L4 started.

Oh well, there was a lot more in that I guess. Is there a way to create a protoype to test it? What
needs to be done to make it work?

Heh. Work in progress. (Ask valerius). Actually, we need discuss many things before just implement it.
Most think we make stupid work. Get GRUB and reuse it. But we will lost MicroFSD and, as result, well
be highly depended on GRUB. It is as small example.

valerius

Joined: 03 Apr 2005
Posts: 50
Location: Elizovo, Kamchatka, Russia
Posted: Sun Oct 29, 2006 2:12 pm

2osfadmin: As I understand, MiniFSD works only in protected mode. There is no way to use
it's support for handling subdirectories in real mode. Also, MiniFSD is a DLL. DLLs doesn't work
in real mode.

2Viking: Yes, a MicroFSD can be extended to support subdirectories. I was said that bootJFS
from Pavel Shtemenko can handle subdirs, so, we can make it too. This will affect nothing --
JFS MicroFSD supports subdirs, but OS/2 loader does not use it. But we can use it.

OS/2 kernel uses MiniFSD to read files in protected mode, but at the beginning, when OS/2
disk subsystem drivers has not loaded, the loading of these drivers is performed by MiniFSD,
and MiniFSD uses a function from the kernel to read sectors from disk. The kernel then switches
to real mode temporarily to call BIOS disk read functions. Then it switches back to protect mode.
After disk drivers are loaded, the disr read is performed by them, and switching to real mode in
not needed anymore.

We use L4, so, we can't switch to real mode and call BIOS functions. So, th first drivers must be
read from disk before L4 is loaded, i.e., we must do so in loader. But then we can load by loader
a set of all required drivers and dlls and a fully-functional IFS driver. So, the basedev loading
phase and minifsd are not required and unnecessary.

BTW, OS/2 PPC also had no minifsd, instead, all required files are loaded by system loader, not
kernel. And they're in loader config file, not config.sys. The loader loads all these files in memory,
and passes them to bootstrap initial task. The bootstrap then serves these files to the rest of the
system. Then, the files loaded in memory which include servers, libraries and drivers, are ELF-loaded
and relocated by the task Server. The bootstrap tast directs the task server, which files in which
order must be loaded and launched.

First, the Personality-neutral (PN) servers are started. These PN services include device drivers (yes,
they're not specific to the OS/2 Personality, other personalities can use them too), Hardware resource
manager (HRM), System logger, etc.

Then OS/2 personality starts. It's main server parses config.sys and loads OS/2-specific servers.

I think, this is more appropriate in microkernel environment, so, osFree must do things similiar way.
_________________
WBR,
Valery V. Sedletski

valerius

Joined: 03 Apr 2005
Posts: 50
Location: Elizovo, Kamchatka, Russia
Posted: Sun Oct 29, 2006 2:33 pm

PS: Now we use a prototype environment, The FreeLdr is extended to include GRUB routines for
loading L4 kickstart. The problem was with calling MicroFsd functions from Loader. Now the problem
seems to be solved. The MicroFSD is clled correctly, but the problem remains that GRUB functions are
32-bit, they are written in a 32-bit C, and we use 16-bit C, and int type has different size -- 16 bit, not
32, the pointers are FLAT in GRUB. And FreeLdr is a 16-bit program working in real mode, so we must
correct these inconsistencies. Also, we must add support of relocating binary images to high memory,
to have no 1 Mb constraint of available RAM.

Then, the loader must load a kickstart bootstrapper, l4 and servers, and launch kickstart. Kickstart will
configure and launch L4, L4 will launch sigma0 and roottask. We use a pingpong test pgogram as a root
server. When it will work, then we could replace pingpong with a real rootserver.

A rootserver must do things, similiar to the OS/2 PPC bootstrap task. I.e, launch PN services and personalities.
Personalities include OS/2 Personality (our main goal, not yet implemented ), L4Linux personality. There is
already several different versions of L4Linux implemented, we must select one of them. Yuri suggests to use
L4Linux as a common environment for osFree build system and development. -- Now some of osFree developers
are working under Linux, some under OS/2, so Yuri wants to unify a build system, and for this we can use
L4Linux. Now we are attempting to launch L4Linux in emulator. Not successfully, yet.
_________________
WBR,
Valery V. Sedletski