Writing a portable OS?

[Therx]

People always claim their OS is portable but where does the Platform Abstraction Layer stop. Anything that envolves assembly is platform specific. So is the actual task switcher, the virtual memory, the interrupt table, and every other bit of hardware. Even if two architectures have the same bit of hardware they are unlikely to be mapped to the same place. Even in well writen OSes like Tim's (the Mobius) I can't see how they are portable as there is hardware specfic code in the main kernel.

Please fill me in

Pete

[szyszi]

I think that "portable OS" term does not mean that you just have to compile it and you can run it on any platform without any modifications. It rather means that you do not have to rewrite it entirely. For example, you just have to write the new assembly code (and maybe modify the kernel written in C a little). But generaly, you are right that it is imposible to write platform independent OS code.

If you have any question e-mail me at: [email protected]

[Pype.Clicker]

Even OS that claim to be "portable" (i.e. Linux) have looots of platform-specific code. Usually, the platform-targetting is performed by the preprocessor that will show only the implementation of macros that you'll need to see (like, enable() will be translated in "asm("sti")" on x86) ...

This means you may port it 'easily' to platform X by simply re-writing an implementation for those macros ... as long as platform X behaves like platform {A1..An} you already support. For instance, if X has no hardware paging support, there are little chance you can port your OS to X easily ...

I think talking of a "portable" kernel is a joke. Your kernel is multiplatform, not portable. Now, the OS itself may be portable among several architectures and may not need rewriting once the kernel has been ported.

Remember Stallman's #2 commandment: "Gnu is the only Operating System and Linux is one of its kernels" ...

Once linux kernel has been ported to architecture X, the OS (aka Gnu/linux according to R.S.) made of linux kernel + init process + module drivers + system tools like ls, cd + shells + binutils, etc) is portable to architecture X.

[Therx]

My problem is that I initially though, ok, I'll but all processor specific stuff in a layer. But now I'm starting to realize that that will not do because the difference between a PC and a Mac insn't just the processor but also all the hardware. So I thought, fine, every single driver will be a module. And now I've suddenly realized that there isn't much left!!!

Pete

[Solar]

You might want to check out Project UDI (http://www.projectudi.org). That's a platform-independent driver architecture. (Kernel provides a specified environment, and drivers can run across various platforms unchanged as long as the platform provides the UDI environment.)

[Pype.Clicker]

hum ... i can't remember whether UDI addresses the problem of porting the driver for os X on platform A to os Y on platform A or porting for different platform too, but i thought it was platform-specific ... maybe i need a refresh on this ...

[Tim]

An OS kernel is one of least portable pieces of code you can write. Although its job is to make a portable interface available to applications, there will always be large chunks of code which are platform-specific. The more portable you make your code, the less efficient it is; more portable code needs to be more generic, and isn't as well optimised as code written for a specific type of platform.

[Solar]

hum ... i can't remember whether UDI addresses the problem of porting the driver for os X on platform A to os Y on platform A or porting for different platform too, but i thought it was platform-specific ...

Both.

OS X on platform A and OS Y on platform A could use the same driver binary.

The binaries for platform A and platform B can be compiled from identical source code.

[Therx]

I want the driver interface to be through the traditional open, close, read, write, etc. The only reason I'd change my design is if I find a standard that has a wide selection of drivers already writen for it (Project UDI doesn't seem to have this).

What does everybody else use?

Pete

[Pype.Clicker]

i'm trying to design a more comfortable way to handle devices than legacy open/close/read/write. People that claim that "everything is a file" tends to forget that there's nothing like /dev/eth0 and that unlike a hard disk, a sound card expects packet to be delivered on specific timings and that a read() on /dev/video has very little meaning ...

I see to much things going through ioctl() calls and i plan to have more specific device class with well-defined interfaces that will play the role of ioctl(), without the obscurity of the way it is implemented (... well, at least i'll attempt to achieve this goal. Whether i will or not is left for future evaluation )

[Candy]

My problem is that I initially though, ok, I'll but all processor specific stuff in a layer. But now I'm starting to realize that that will not do because the difference between a PC and a Mac insn't just the processor but also all the hardware. So I thought, fine, every single driver will be a module. And now I've suddenly realized that there isn't much left!!!

Pete

Mac's and some other systems also support PCI stuff. Lots of systems support SCSI general stuff. There are VERY much systems supporting TCP/IP. If you put those in system-independant code, you still have a lot of stuff. Mainly, the algorithms and protocols.

Somethings that I am putting in OS-independant code:
-Scheduling function, the one that actually picks the next task
- FS code
- Network protocol stacks
- all drivers (plugging a USB device not made for a mac, in a mac running your os would still allow it to work... USB == USB right)

even better, if you put all the very system-specific code in a separate directory, you only need to make a new fork of those functions, since all the others are independant. Doing this would make it, in fact, portable

[Therx]

The only independant code I'm going to have is:-

• Task Manager (not switcher)
• Device manager
• Memory manager (although there will be a lot of platform dependant support routines for this)
• System Call Interface
  
  And everything else is either part of my 'Processor Abstraction Layer', a loadable device driver module or a loadable object driver (e.g. TCP/IP Protocol, FAT12 Filesystem, GUI)
  
  Pete