OSDev.org

there will be a dynamic loader/linker soon, but for now i'm sticking to compiled-in binaries, for the sake of simplicity.

so you have your 'modules' %incbin'd into your kernel ? that will for sure simplify to work of loading the kernel, but even assuming every module has its init function at offset 0, how will you
1. invoke functionnalities of the module -- say you've written the keyboard module that initializes by registering an interrupt for keyboard IRQ, how do you access the "read_keyboard" function that would allow the kernel to extract bytes from the module's internal buffer ?

2. allow module invoke functionnalities exported by the kernel such as print, alloc, etc.

3. allow module to invoke functionnalities exported by other modules ?

Nah, definitely, the scheme you propose sounds completely unusable to me ...

Pype.Clicker wrote: so you have your 'modules' %incbin'd into your kernel ? that will for sure simplify to work of loading the kernel, but even assuming every module has its init function at offset 0, how will you
1. invoke functionnalities of the module -- say you've written the keyboard module that initializes by registering an interrupt for keyboard IRQ, how do you access the "read_keyboard" function that would allow the kernel to extract bytes from the module's internal buffer ?

2. allow module invoke functionnalities exported by the kernel such as print, alloc, etc.

3. allow module to invoke functionnalities exported by other modules ?

that's the beauty of this system. it uses modules within modules, most of them eventually leading up to an isr. they would be called via interrupts, and would therefore be very simply used.
btw: i may make the multitasking software-based after all, since it's beginning to seem simpler ^^;.

i must be confused ... are you saying you'll %incbin malloc.o every time you need to perform a memory allocation ??

if so, how the hell could you keep state variables ?

A lot of words, but NO job..

Pype.Clicker wrote: i must be confused ... are you saying you'll %incbin malloc.o every time you need to perform a memory allocation ??

if so, how the hell could you keep state variables ?

i'm not saying that at all. i'm saying that i'll make a function in the core kernel code for malloc(), %incbin malloc.o, and have that be called. for single-function code, the code will be %incbin'd into the isr as part of the function's code. i'm not eliminating all calls, or making things inline. i'm just eliminating a bunch of the calls that would specifically slow down the system and crash it if something was missing.

unknown user wrote:i'm not eliminating all calls, or making things inline.

But how could another module know of malloc's existence, if all you're using is incbin?

i'm just eliminating a bunch of the calls that would specifically slow down the system and crash it if something was missing.

You can't have much confidence over the quality of your own code if you think that something as simple as a dynamic module loader would crash the OS.

malloc would be a syscall (dos does that, and i think linux does too), so it could be incbin'd in there.
true, i don't have much confidence in my code, but my point is to be defensive, so that i can create code as bug-free as possible and can counteract any bugs that may be introduced. since i have a few things going on before the exceptions are addressed, i put everything on a defensive stance until after i have an exception system and a module loader.

malloc should be a normal function, for speed. Remember that syscalls (e.g. through an interrupt) take many times longer than a normal function call.

malloc's memory should be backed by the kernel allocator, which allocates large blocks on each call, and can be accessed through a syscall. malloc's job is to split these blocks into smaller portions.

Whereas it's easy to recode defective pieces of code as you go along, it's much harder to change the overall design, as you are proposing.

i'm not really changing the entire design, as you are suggesting. i'm setting up the kernel to do as little as possible, while supporting as much as possible, and i want to eliminate as many inter-kernel calls as possible while still facilitating their communication, and all this without sacrificing a lot of speed or power.
no, interprocess calls won't usually use interrupts, but they will if it is nessisary. the malloc() example is less than a good example of this, because it will be used (imo) almost exclusively by programs and execve(). therefore, it will use an interrupt. but for something like the drivers in the vfs, they would be assembled or linked into the correct places within the functions, which all constitute one interrupt per 5 or so functions.

the kernel is coming along pretty well, but if anyone wants to join the project, we'd be glad to have another coder. right now i'm not only doing most of the kernel, but a large chunk of the gui also, and the help system, as well as the apis for the gui and kernel.

are you trying to be the next torvalds? well anyways, i wish you good luck on this, because i know how hard it is for group projects to succeed. also, i read something about a GUI. i must say dont bother until your kernel works. btw, is your C++ code working?

dude, you sicken me. What kinda show you runnin here? You already have cups, Tshirts, mouse pads, bumper stickers! Where's a product? WTF!! You scare me. Do you even have a kernel that prints "Hello, World!" yet? My goodness. You guys will kill this porject within 2 months easy. WAY too ambitious.

...

And everything that you've heard about managing agroup being hard, it's dead true. A project with just 5 people i was in is dead now because 2 members didn't like eachothers idea and 1 of tehm wouldn't let the other explain. We couldn't get them to coopaerate. Next day(after an argument in a meeting) the project had lost 2 main members and i was the only main poncho left. I quit right then.

...

People are hard to manage. Try making them work together w/out visual contact on irc where no one can make someone be quiet. It's hell. That's my $.02

Regards,
mr. xsism

I agree with Mr. Xsism. I don't know of any OS project which succeeded with more than one person. Even Linux started with just one person.

Where people come to gether comes argument after argument, opinion after opinion. It is a question of tolerance and listening to the others to make them feel content.

Working to gether brings the need of accepting compromises sometimes. you canna hold a group to gether when you aren't willing accepting other opinions. Nor can you stay in a group.

The more: in an ordered group discussion, NO ONE is to tell the other one to hold his trap. There have to be rules for discussion agreed before start.

But as far as I have learned - especially during study time - working together often looks like this: one does all the work whilst the others are bickering about it doing quite nothing, especially when you have the bad look to have some gits in your project group.

unknown user: what is this tackle thing for? os dev basic dialect? the more: No, I don't want to join. I have my very OWN os-project running and it is running good!

stay safe folks