OSDev.org

I had no idea how many operating system projects there actually were until I found this site.

It's sad to see that a lot of them have not really taken off, a lot of effort goes to waste.

I would to start promoting the idea of tackling operating system development as a community instead of as an every-man-for-himself approach. One person does not have to write the entire operating system by themselves. I know that everyone, myself included, takes pride in the amount of code that they write, but projects are not getting finished. I've made an effort to create or contribute to reusable operating system projects. BMFS and Pure64 come to mind. I found https://github.com/omarrx024/lai, an os-independent ACPI implementation (props to Omar). I would like to see more projects like this.

There's no reason we can't all share libraries for:

1. ELF Loading
2. Memory Allocation
3. Network Protocols
4. GPT
5. FAT32
6. Windowing System

I mean heck, if we agreed to a standard for driver interfaces, we could even share device drivers too.

What do you say we get the ball rolling on this? Who thinks it would be good for the community to share more projects?

Not necessarily so. People learn from it. If they don't quit too early.


Does it need tackling? We've got Windows and Linux (/BSD/etc) for general- (and not only general-) -purpose computing and some stuff for special cases (embedded, real-time, etc etc). There's no shortage of OS/kernel code.


That means the community members would need to:

• work together, socially
• across the globe and time zones, decentralized, without physical presence and personal touch
• somehow have their skills matching those with whom they work, otherwise it's struggle and frustration
• work in similar pace for things to come together timely
• somehow resolve disputes as to who does what, how and when, without quitting or forking, otherwise it's not a communal effort anymore, right?

How do you intend to achieve that?


For something to be reusable, it needs to be properly implemented and documented. And the potential reuser(¿?) needs to understand it and all the implications. For inexperienced and ignorant people it may be an overkill. Further, it may be hard to simply pick and choose. APIs may be hard to satisfy when one doesn't yet have implementations for X and Y that Z needs (because they don't want to use the existing X and Y or don't understand them yet).


Is there any problem helping projects like Linux, ReactOs, etc instead of doing something from the scratch yet again?

Hi,



For the majority of people here the goal is to learn about OS internals (and not finish writing an OS); and in this case none of the effort is wasted and you can't skip pieces without learning less.



Every few years someone suggests that everyone else works together on a single project. It never works. For the majority of people "learn less by letting other people do it" doesn't make any sense. For the minority of people (where the goal is to finish an OS eventually) they all have good specific reasons for not just using (e.g.) FreeBSD and saying they're finished without doing anything.



Woah there! For my OS project there will never be shared libraries - in my opinion they're an intolerable disaster and need to be replaced, either by isolated services (communicating via. messaging, for much better security and scalability) or be statically linked (to avoid dependences, breakage and malicious code injection risks).



We can't even agree on standard driver interfaces for boring/simple devices.

Mostly, you seem to be assuming that all operating systems are essentially the same (and therefore code can be shared). This is a mistake. For most of the things you've listed there's a small amount of "potentially shareable" code, and a large amount of code that is not shareable between different OS designs because it depends on things like the interfaces between upper and lower layers, the interface to the kernel, the OS's permission system/s, etc.



I think you should start by trying to design a "standard" interface that USB device drivers can use to talk to a USB controller driver. Note that this interface should include things like hot-plug events, isochronous ("fixed rate") transfers, hardware fault reporting and statistics gathering (bytes and packets sent/received, etc), and power management; and should describe how (and if?) USB controller driver starts USB device drivers after/during enumeration. Don't forget that some people are doing micro-kernels (where USB controller driver and USB device drivers are in separate processes), and most people will insist on asynchronous interfaces.

After you've designed it; post a complete description somewhere and then brace yourself for the resulting fire storm of suggestions, objections and arguments.


Cheers,

Brendan

First, I'm going to address a few misunderstandings.

1. No, not a single project that everyone works on. I like seeing different operating system projects. I just mean some reusable components.

2. I said we could share libraries. I did not mean shared libraries in the sense of the shared object file. Libraries can be shared by either static library files or just source code.

3. I don't want every operating system to be the same.

Here's a couple of points that have been made that I agree with.

1. For new users, using an API is overkill. You're right.

2. Standardizing a driver interface is difficult. Why not use the standard from the Linux kernel? It's already tried and proven.

Here's some counter arguments.

1. I'm not opposed to working on React OS or Linux, but a lot of their code is not written to leave the project. I suppose this wouldn't be that hard to patch though, I haven't given that a shot though.

2. Collaborating on a project is not hard. Ian Seyler and I have been doing it without issues for a while. Sometimes we disagree, and that's fine. We'll either pick an idea or compromise. It's not difficult.

3. You can still decide to write an entire operating system yourself, to learn about it. I just suggest, in doing that, that the code be made to use in other projects.

Also, am I hearing that we could use a reusable USB driver? I could definitely take this up. I've been wanting to write one for Pure64.

Note - Sorry for not using quotes, I'm using my phone.

Hi,

Just picking one of your points:



From: https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html


IOW Linux' driver interface only appears stable if your driver makes it to the source tree!

There are, however, attempts at creating stable driver interfaces, such as UDI and ?EDI / ODI? One of these was, for a while, run by a member of these forums.

https://xkcd.com/927/

Cheers,
Adam

Adam,

Thanks for your input. So let's say we can't standardize it. Does it have to be standardized? Perhaps that would make it harder to be innovative. But as long as it's reusable, the operating system project that uses it can be responsible for the glue that makes it work with the other components. As long as there aren't too many assumptions about the environment made by the driver, I can't see this being a problem.

Hi,

I certainly wouldn't want to dismiss a project like this out of hand and if you are serious the go for it.

I guess scepticism (or cynicism!) comes from seeing various attempts at common interfaces and even OS toolkits that have fallen by the wayside. At one point, I even got talking with "quok" about coming up with such a project that could be donated to the OS Dev community. In those days I was at uni (or just out of uni) but like with so many projects, real life gets in the way.

I just wouldn't want anybody to take on such a project expecting to revolutionize the OS Dev world. So many people are in to this casually, for their own education, or because they are control freaks (no offence intended by this term!) who want to do everything their way and therefore, by definition, will not use somebody else's code.

Good luck and if you proceed view it as an educational project and you won't have lost anything if it doesn't go as expected!

Cheers,
Adam

AJ,

I can appreciate that. Maybe the interface doesn't have to be standardized, that could be asking too much.

I guess the best that I could do is keep writing reusable operating system components, promote their usage, and hope that some people do the same?

If I had a reusable component, like BMFS or Pure64, that I wrote for other people to use, could I write a section on the wiki about it? While they already have documentation, the wiki seems like a goto place for tutorials like that.

Hi,

By all means! Best to create it in your user area initially and it can be moved in to the main wiki once it has at least the skeleton of an article!

Cheers,
Adam