OSDev.org

Hello all. I am interested in OS development and I am thinking about cross platform operating systems. I dont really have any plans to make one but I am very interested in the technical details. What do you guys know about cross architecture operating system development? From basic stuff such as x86 and arm, to doing something more complicated and porting an OS to something like a AVR chip. Any thing about how stuff like this is done would be interesting. Thanks! -Setra

Easy: you compile it once for every arch.

But different archs have different memory management systems. Some dont have MMU's. Some have different types of allocation... Does the compiler really handle everything?

No, you have to write everything by yourself. Always keep in mind when OSdeving: computers by themselves are stupid and useless. They require a programmer to do something useful.

You have to write the arch-specific parts seperately. Every arch-specific part has a bootstrap function, which has the same name on every arch (e.g. "arch_bootstrap"). This function gets called from the main kernel entry point.

When compiling, you decide which arch should be compiled. Only the generic code and the code specific to the arch you compile should be given to the compiler. You can't really figure out on which arch you run at runtime, so you have to know that at compile time.

Real-life examples: Linux and seakernel

You have to put all, or nearly all, of the architecture dependent stuff into seperate files, and develop a standardised interface for interacting with them. You have to ask yourself questions such as, "What would a virtual interrupt controller have to look like, if it was to be an effective disguise for the real, and multifarious, hardware underneath?"

With the hardware dependent stuff split off, only it would have to be rewritten in order to port the OS to another architecture.

But different archs have different memory management systems. Some dont have MMU's.

There will be so many other differences between MMU'd and MMU-less processors that they don't quite lend themselves to even run the same kind of code. After all, trying to run a deskop on an Arduino is a purely masochistic task.

Most of the now relevant architectures actually have an MMU. You need a bit of glue code that creates and destroys address spaces and maps chunks in them, but the majority of what's your OS can be reused regardless of these differences. So yes, for some 90% the compiler does actually do the work for you, and it's quite easy to point out the parts that aren't if you keep them properly separated.

Hey guys. I am interested in learning about hardware abstraction layers. Do you guys have any cool resources about them, or any thoughts about them, or thoughts about implementing them. This is not really so much of a question as just a general request for potential discussion or design strategies.

Are you serious? You opened like 3 topics the last 2 hours. Maybe you should start using Google?

"Please stop posting non-informative and non-specific questions. Respect others' time. Debug your stuff first, don't throw it at people."

Pretty simple, really.

The applications running on your OS don't want to write custom code for each piece of hardware that it might encounter. So your OS is responsible for making all of the various devices out there "look like" a "generic" device. So all of your storage devices will look basically the same, as will your audio devices, graphics devices, input devices, etc.

If you can come up with a "prototype", or "virtual" device for each type of device you want to support, then all you need to do is "translate" between your real device and your "proto" device.

Something else to keep in mind is that there are rare cases where you want to allow "direct" access to the "real" device, but in most cases you want to give "shared" access to your "virtual" device. Take the sound card, for instance. In most cases, you are going to want to give each application a virtual device to talk to, and your OS will need to "mix" all of these together, and send the combined data to a single real device. The same goes for the keyboard, and the video card, and all of the various storage devices.

As for how you pull this off, there are a few ways to do it. Linux seems to prefer using a common struct that holds a bunch of function pointers that the driver fills in. Then the OS exposes all devices as very generic "block" or "character" devices.

Windows seems to hide all of the devices, and forces the application to go through the windows API for almost all device communication. On the driver side, it relies heavily on C++ templates to provide a framework for each device type. Other people may be able to provide more details in this area than I.

Personally, I am going with more of a C#/Java/JavaScript approach, where specific device classes simply extend generic base classes. Hopefully this simplifies the whole process, but that remains to be seen.

Let us know if you have any specific questions about devices, or anything else for that matter.

The trick (like hardware abstraction) is to decide at what level you want to "abstract" the hardware.

Simply using C gives you a low-level abstraction that you can use (and that most OS developers use) to write code for multiple platforms. For high-level abstraction, look at how Java and .Net provide a complete virtual environment that the application can rely on to be available regardless of what physical hardware is actually available.

These two examples represent two extremes of abstraction, but you can also choose something in between.

SpyderTL wrote:Windows seems to hide all of the devices, and forces the application to go through the windows API for almost all device communication. On the driver side, it relies heavily on C++ templates to provide a framework for each device type. Other people may be able to provide more details in this area than I.

Windows exposes devices as file objects in much the same way Linux does. However, they're not usually displayed to the user, and you need to use the native API to get access to them. When it comes to the kernel side, Windows drivers also expose functions like Linux does, but there are a lot more functions that a driver handles. You fill out a structure of function pointers, which contain things like file operations (read, write, ioctl), PnP commands (start device, stop device, query resources), and power management commands. This is Windows Driver Model, and although there are other frameworks to make programming drivers easier (KMDF for kernel drivers and UMDF for user-mode drivers), none of them involve C++ templates.

setra wrote:What do you guys know about cross architecture operating system development?

I know that if you have some really powerful abstraction, then there is no problem with crossing architectural (hardware) boundaries.

In my case it is just a small part of jEmbryOS, that should be changed to deliver the same Java abstraction for any existing hardware architecture. In particular it includes the Assembler and Compiler projects, and small part of core jEmbryOS project. Everything else can be leaved as is.

If we speak at a bit more general level then it can be said that we can hide the hardware from higher levels. But it has some costs attached. The most important cost is the efficiency of an OS. To overcome the efficiency problem there are a few options. First - just create some abstract hardware and connect it to a real hardware using different virtualization techniques. Second - go higher and create a virtual machine and connect it to the real world using a mixture of drivers and compilers. And finally there is one more option - just buy an Android device and push it's fancy buttons remembering that the button will be the same on a lot of very different devices.