OSDev.org

I have a couple of suggestions/ideas that perhaps others have thought of before, but I'd like to get it all in one thread here.

1) How about we have a monthly code-fest or hackathon where we write code all day (or another day for folks who are employed full time or otherwise busy) and upload a zip file with manifest and short description of what's in there to a monthly code-fest/hackathon page on the OS FAQ Wiki?

2) How about a dedicated code library page, where OS devers of all persuasions (monolithic, micro, nano, exo, foo, bar, whatever) post their code: demos of task switching, demos of single or multitasking, demos of memory management, standard or non-standard C library functions: anything that OS devers might find useful. VESA code. BIOS stuff. Different implementations of printk, examples of ATA disk drivers, anything and everything. Grab it all into a well organised and searchable code library.

What do you think? Mods, can we make a code library or hackathon or similar idea happen on the OS FAQ wiki or elsewhere? And I mean a biggie: not just a few hello world boot sectors. The biggest and best code library for OS devers (leaving out existing kernel code like Linux and the BSDs etc, of course!)

While I don't want to be excessively cynical, I suspect that when you start giving people code like that, rather than actually learning stuff, they come by the forum and ask why their hodge-podge of code they don't understand and didn't write together doesn't work together.

It'd be great if people used example code like they should. But they won't, and giving them more would just encourage them to *not* use it like they should.

Second, there are already OS code libraries, and if I understand correctly (do correct me if I'm wrong), being one was never the purpose of the OS-FAQ.

Pax tecum,
Qui te vexat.

Code libraries are essential. You don't learn anything about programming just by reading descriptions or datasheets or books.

While it's not the purpose of the OS-FAQ, a FAQ on a programming topic is not complete without programming examples, in my view. And so what if there are already code libraries. Six complete and advanced ones are Linux, OpenBSD, FreeBSD, NetBSD, OpenSolaris and Minix. There are others.

What are the code libraries you mention? Remember, I'm not talking about hello world boot sectors, but good code that can be used for educational purposes.

I never mentioned forcing anyone to contribute their own code to it. ::) Also, there is absolutely nothing wrong with using someone else's reference ATA disk driver until you get around to writing you own, for example if you're more interested in file system hacking. I don't need to tell you how awesome and huge an OS project is. Example and reference code is essential to helping newcomers and more advanced programmers (researchers, enthusiasts, etc).

The purpose of the OSKit was to provide a framework so that you could get on with the business of research on operating systems without doing all the drudge work of drivers and whatever. It was a great idea, but unfortunately it has been left incomplete and is a huge mess and complicated. I sympathise with the original goals of the project. If you want to get to memory management and play with that right now, wouldn't it be nice to take the OSKit, take out the memory management, and replace it with your own?

It is also not a repository to discourage programming, learning, or to provide anyone with code for their homework. If we don't create a code library just for those cynical reasons, then we've put petty reasons and mere excuses ahead of providing a real educational experience with good code, our duty as humans to help other fellow humans, etc., etc.

I would say, very nice idea indeed - but better make it into an independent project. Perhaps on SourceForge? We could link to it, and perhaps announce the next upcoming "coding day" on a regular basis.

I don't really see where it would be beneficial to do this within the scope of the OS FAQ - the additional maintenance workload aside, I fear that most of the guys here are quite busy with their own respective OS...

well, the current approach i try to promote on MT's FAQ is to publish the 'bare bones' you need to get starting on a subject. That includes e.g. the code snippets for accessing PCI configuration space and perhaps the structure describing common stuff, but no PCI scanning code because it is too much dependent on your actual OS design ...

Whenever possible, i post things on MT *first* and then reuse the post in Clicker (that makes it public domain -> GPL which is okay, i think).

maybe the 'small OS with Source' page could be pointing at CVSes too, for people that have world-browsable CVS ...

Hackathon ? like the spirit ... it would be more fun if we had it alltogether in the same room, too (remember of demoparties ?), but i fear i would have _little_ days where a hackathon could actually take place (Only 4 years left before '30 and yet a thesis to write )

With the whole "source examples" idea, I think rather than showing how to do something, we should really show why we do something.

The problem I find with understanding source files is that they just implement, they don't explain what's going on. I think we need better tutorials rather than simply a source library.

100% ACK. Source is documentation for computers, not for humans.

Pype.Clicker wrote: Whenever possible, i post things on MT *first* and then reuse the post in Clicker (that makes it public domain -> GPL which is okay, i think).

You are perfectly OK to do the reverse, too, as long as no-one else contributed to the GPL code. If all of Clicker is your work, you could release it as PD or sell it for big bucks or whatever. Only the parts contributed by others under the GPL you cannot release that way, because the copyright for those parts is still with the authors (unless you got something in writing that they waive their copyright to you).

@Pype: Thesis for Doctor?

How about _pseudo-code_ instead of regular code?

For example, drivers in pseudocode - primitive actions upon devices, and sequences of those actions, etc. Ditto with scheduling, memory alloc, everything.

When someone implements something, they can write it out in pseudo-code and contribute (if they are so inclined).

I understand what you say about source files giving an implementation rather than an explanation. I also have that problem, trying to figure out the "why" question. I will definitely take that on board.

I also like the idea of having it on SF instead of the OS FAQ, and linking to it. That's a great idea.

Getting together a kit like OSKit but better than OSKit without the COM nonsense would be an ultimate goal for the project, along with documentation that explains the "why" and not just "this is what you do."

I would also like a hackathon in a room, but unfortunately we are spread out all over the world... it would be expensive for us to all fly half way around the world to meet! It would be a virtual hackathon in an IRC chat room to keep in touch while we code or something. That can be sorted out later, after the code library gets on SF and there's something worth downloading.

Pseudocode sounds like a reasonable idea. I don't mind reading good pseudocode, especially with excellent documentation (Knuth's web system comes to mind. I like literate programming a lot).

Best wishes to all.

There's a problem with creating as OS Dev Kit, namely that the kit can really only cater to one design methodology (eg. micro, mono, exo -kernels. Then you also have the sub categories like user space drivers, interpreted drivers, user space process and memory management, just user space memory management, just user space process management, capabilities or not, Object Oriented or not and so on. Then you can add to that list with "chosen language", some people prefer C, some C++, some Pascal, some ASM {there are also several different types of ASM; GAS, NASM, FASM ...}. There's probably also other things I've missed as well).

So essentially you would need a seperate kit for every concievable design, only catering to, say, "common-mono with POSIX" will only be useful to people making monolithic UNIX clones in which case, what would be the point? Especially when you have to create several versions of the kit for the different languages in order to fit everyone for even that limited slice of possible designs.

I agree that pseudocode explanations of how and why to do things would be useful though.

AR: I disagree with that. With modular components, and well-defined interfaces, then it is possible to make those modular components work with anything. Did you know that the NetBSD UVM memory manager was taken out "as is" from NetBSD, a monolithic POSIX UNIX, and put in OSKit, which was used as the basis for the post-CMU Mach microkernels?

Also, Linux device drivers were taken out and put in OSKit, and again, they were used in a microkernel. Also, Minix does POSIX very well despite being a message-passing microkernel.

The problems you speak of arise when someone is not experienced enough to design and think abstractly. It is certainly not necessary to have a monolithic POSIX code library, then a microkernel code library... they would all be modular components.

The languages issue: well, all languages are compiled to the same machine language on the same architecture, only the calling convention and infrastructure (crt0.o, etc) is different. Using the convention that the BSD kernels use to do a software interrupt for a system call means that you can use any language you like for the main system library, or whatever.

What will be helpful to everyone is excellent documentation and maybe pseudocode, and what will be useful to most people is a code library in plain old C with NASM assembly code (GAS users can easily translate, but NASM users tend to start with NASM and are frustrated by AT&T syntax). Those using Pascal, Java or whatever can then use the pseudocode.

If you've actually learned the language rather than copy+paste everything blindly then you can work pseudo-code into your own source. Eg (Part of my ReadCDSector() function):
was originally Anyhow, I like the idea! If it goes ahead, I'll make some pseudo-functions to submit.