OS/3 Boot System: Prototype 1

[admin]

KC5TJA



Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA

PostPosted: Sat Apr 02, 2005 6:22 pm Post subject: OS/3 Boot System: Prototype 1 Reply with quote

Please see http://www.falvotech.com/projects/os3.php for my current implementation plans to offer the OS/3 group a workable boot system. Comments are of course welcome.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website

[admin]

KC5TJA



Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA

PostPosted: Sat Apr 02, 2005 7:14 pm Post subject: Reply with quote

I forgot to point out that the specifications for LEAN can be found here: http://freedos-32.sourceforge.net/showd ... age=leanfs

Update: Release 0.1 of the filesystem specification is now available. The big changes are how undeletions are handled in LEAN, and on how FSDs can scan the disk looking for the primary and backup superblocks. This latter feature was requested by me as part of discussing how OS/2 / OS/3 micro-FSD and mini-FSDs work. Smile

LEAN is a cool little filesystem. I'm glad I found it.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website

[admin]

KC5TJA



Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA

PostPosted: Thu Apr 07, 2005 10:07 pm Post subject: Reply with quote

Just to let folks know, I'm continuing development on the implementation of FORMAT within my "ROSE" environment (Research OS Environment). It's currently employing SCons as the build environment, because I don't particularly feel like editing and maintaining Makefiles. It also improves portability, since it largely eliminates the need for me to make special-cases for different people's compiling environments, and produces a much cleaner directory hierarchy. It also integrates my unit test framework quite well, which is nice.

FORMAT currently writes the superblock and a null allocation bitmap to the device you specify for it. I'm currently implementing a simple volume management subsystem so that I can properly create the root directory for it and actually allocate sectors from the disk image. This ought to allow me to complete the FORMAT command. At this rate of pace, I expect the FORMAT utility and the concommitent(sp?) "OS" API it uses to be workably complete in two weeks time.

It's amazing how much effort has gone into FORMAT so far, over this past week. The software is evolving (I use test-driven development techniques) into a clean, exokernel-like environment, where applications link against a librose.so file (or, for those who prefer OS/2 naming conventions, ROSE.DLL), which constitutes "the OS" (as seen by the applications, of course). So far, it includes block device management, and volume management is coming soon. Right now, the needs of the formatter is driving the design. Currently, LEANFS is hardwired into the code. When it is time to support IFS, I will do so at that time. The API is clean enough to isolate this change for the most part.

The OS APIs are designed using an object oriented methodology, largely derived from CORBA specifications. API functions are named using the following convention:

Code: Select all

return = Module_ ... _Interface_MethodNameInCamelCaps(...);

It makes for some pretty verbose code, which some might find offensive. However, it equally makes for trivially easy-to-read and easy-to-maintain code too.

As much as possible, I try to follow the object oriented programming dictum of let the object with the state do the work for you instead of exposing state. Sometimes, this isn't always possible, but nonetheless, this will often explain why the BlockDevice "class" has both an IsLocked() and IsNotLocked() "method".

ROSE supports a concept that I've been working on for some time -- the idea of an OSI-like filesystem "stack." Basically, I've identified seven layers:

1. Physical Layer -- the media itself.
2. Sector Layer -- This is where most "low-level formatting" takes place, as it deals with reading and writing individual sectors to the media.
3. Allocation Layer -- This is where we maintain which clusters are actually allocated or not. Note that a cluster need not be the same size as a sector.
4. Fork Layer -- This is where individual streams of data start to materialize. However, forks are addressed only by their starting block number, or some other similarly primitive ID.
5. Object Layer -- This is where we aggregate one or more forks into a thing we call "a file." E.g., OS/2 EAs and ACLs can be represented as individual forks, along with the normal file data. But in this layer, we treat all three forks as a unit.
6. Naming Layer -- This is where directories and files as the user sees them become apparent. It's also where the volume label and other identifying information is maintained as well.
7. Application Layer.

While the ROSE API doesn't directly expose the existance of these layers (just as the BSD sockets interface doesn't expose APIs for each of the TCP/IP layers), the software is nonetheless built with this layering structure in mind. It appears that OS/2 itself was built largely in recognition of this too, as FS_* functions rely on FSH_* functions, etc. Many of the FSH_* functions appear to resemble my current BlockDevice_* and future Volume_* functions.

At any rate, I'm very excited by ROSE, and the progress being made on it. Before I go to work tomorrow, I expect to have a tarball and/or Darcs repository online on my site for ROSE, with my current level of progress.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website

[admin]

KC5TJA



Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA

PostPosted: Fri Apr 08, 2005 3:44 pm Post subject: Reply with quote

Bahh -- I couldn't get to a releasable point, and I have to get to work. I'm actually going to be doing some major internal restructuring, though. But then again, I still have two weeks to get the FORMAT tool out and done. I hope to have it completed by then. Please stand by. (I do intend on posting some sources this weekend, but I just don't know when. Obviously, I can't do it while I'm at work.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website

[admin]

prokushev
Site Admin


Joined: 25 Nov 2003
Posts: 100


PostPosted: Tue Apr 12, 2005 11:52 am Post subject: Reply with quote

Only one small problem. We need OS/2 version of QEMU to work with your tools.

Any takers?

Wink

wbr,
Yuri

[admin]

KC5TJA



Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA

PostPosted: Wed Apr 13, 2005 2:42 am Post subject: Reply with quote

Only one small problem. We need OS/2 version of QEMU to work with your tools.

While it would certainly be nice to see QEmu ported to OS/2, I'm not hedging my bets. My goal is to get something that boots via, e.g., a floppy disk, or something that someone can place on an unused harddrive partition. I use QEmu because it allows me to do my development without having a dedicated computer for the task -- an otherwise useless power sink for me.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website

[admin]

prokushev
Site Admin


Joined: 25 Nov 2003
Posts: 100


PostPosted: Wed Apr 13, 2005 6:32 am Post subject: Reply with quote

Clear. But, actually, we also need to have an emulator. We have (free) bochs and (commercial) SViSta and (not supported) Virtual PC. Bochs is tooooo sloooow. So we need to have something else. QEmu is one of options. And it not depended on kernel drivers (read as easy porting).

So question (not to Samuel ):
Who can/will port QEmu to OS/2? We need only text mode support (no graphics).

[admin]

KC5TJA



Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA

PostPosted: Thu Apr 14, 2005 7:08 am Post subject: Reply with quote

So question (not to Samuel ):
Who can/will port QEmu to OS/2? We need only text mode support (no graphics).

As QEmu uses SDL on Linux to emulate the video interface, and SDL runs on OS/2 (at least some cursory Google searches revealed something to this effect), I think porting QEmu just might end up giving you graphical support out of the box.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website

[admin]

prokushev
Site Admin


Joined: 25 Nov 2003
Posts: 100


PostPosted: Thu Apr 14, 2005 9:18 am Post subject: Reply with quote

As QEmu uses SDL on Linux to emulate the video interface, and SDL runs on OS/2 (at least some cursory Google searches revealed something to this effect), I think porting QEmu just might end up giving you graphical support out of the box.

True. Now just question according who will do it May be I can start work with QEmu at summer, but not now.

wbr,
Yuri
Back to top
View user's profile Send private message Send e-mail
ICQ Number

[admin]

KC5TJA



Joined: 02 Apr 2005
Posts: 22
Location: San Diego, California, USA

PostPosted: Sat May 07, 2005 10:50 pm Post subject: Reply with quote

Contrary to popular belief, I still exist. I just haven't had much in the way of time to hack on LEAN stuff recently.
_________________
Samuel A. Falvo II
Back to top
View user's profile Send private message Visit poster's website