OSDev.org

Memory manager is up and running. What should i do next?
->Write some drivers
->step into multitasking
->write i/o interface

Though writing some drivers is fun for now, later it may require redesigning. should i go for multitasking or writing i/o interface. I guess for writing i/o interface a minimal tasking environment is to be implemented or should i write I/O interface without threading.

tasking is normaly boring, low-level, and hard, so i wrote some drivers before tasking and now most of my drivers dont work

GLneo wrote: tasking is normaly boring, low-level, and hard, so i wrote some drivers before tasking and now most of my drivers dont work

Well, then back to design board with you

@LongHorn: You can do in every order as you want. I recommend to implement multitasking stuff. After all, depending on your kernel structure, you might need it for drivers and other stuff.

most of your drivers will not be designed the same whether you're multitasking or not (that's why the BIOS never went 32 bits, if you ask me ).

when you say "I/O interface", what do you mean ? console interface ? or a generic API to access any driver from user mode ? or a way to register resources and check there's no trouble with those reservations ?

Bringing multitasking will probably modify your console interface aswel, so i'd say "bring multitasking, upgrade your console code alltogether, and then see how that changes what you planned for your drivers".

You may want to grab info about the hardware and start reading it though ...

I/O interface means generic API or hardware independent I/O software. Mobius kernel used to create threads to process user request for I/O access. Mobius i like it, but it isn't working in my system anyway.

LongHorn wrote: I/O interface means generic API or hardware independent I/O software. Mobius kernel used to create threads to process user request for I/O access. Mobius i like it, but it isn't working in my system anyway.

then imho, you should have a clear idea of what your multitasking system will look like first. Having to support cross-process I/O requests (e.g. you issue the request in process X, but when the system is ready to handle it, process Y is now running) as an afterthought wouldn't be fun.

Hello.
I also suggest you to first try multitasking.. So that you'll have some basic platform on which you can desing the drivers..

tasking is normaly boring, low-level, and hard, so i wrote some drivers before tasking and now most of my drivers dont work

Multitasking is not always low level. You can always implement it in any language (except some basic register loading instructions).