What are the most common implementations of device drivers interface? Do people usually use IPC: BILATERAL MESSAGE MAPS (send request to driver/receive confirmation with status) or PROCEDURE CALLS (a table of function pointers)? Do drivers run as usual tasks in the background awaiting messages/requests or are implemented as linked-libraries/DLLs ? How to implement ISR in a multitasking env-t for a driver, as a MESSAGE or by simmulating interrupt in a task (when in the kernel IRQ handler, simmulate INT instruction in the context of the driver task state)?

What ways do you recommend?

The most important thing about human races's "standards" is that there are so many of them. Besides that, most of the important standards and algorithms are patented or secret...

You can study Win32 ways and i see you have some notions since you mention DLL's and DLL's are a specific stuff for Windows only. But take care since Linux and Unixes and other OSes work in different ways.

Basically when you make your own OS it is important to study the cases of all others in great details not only on a "fly over" approach... And you must think for yourself and find your own algorithms Find better algorithms if you can but always choose different for avoiding legal issues; or of course you can make a "unix free clone"

I see no purpose to start making your own OS if you are not able to think for yourself, if you do not have great experience with hardware and low level OS stuff... In addition you must know almost everything and/or really understand everything and it helps IF you have engineered a few huge applications in order to understand architectural issues...

To ease your pain generated by above introduction...

I will tell you what I do in SolarOS:
=============================
-Applications make requests by API Calls
-API calls will fill-in requests for drivers/devices queues
-Drivers and Kernel will examine those queues and react on them in 2 main ways:

1)At iddle time or mode
when applications have finished other non esential stuff like drawing and user message processing. This is the "defered procedure calls" mode.
2)In realtime mode on IRQ requests from hardware.

Normally ONLY drivers attach themselfves to IRQ handling chains. but some spy or filter applications might also. The Kernel IRQ_Main_Dispatcher will give a fair chance to every device and every driver to talk to eachother during an IRQ. Keep in mind that you can have multiple devices on the same IRQ on PCI and multiple drivers attached to an IRQ chain for processing hardware requests.

The queues are normally setup and init by the Kernel and processed by some kind of "processes" or "daemons" inside Kernel BUT IRQ handlers can take over and push a few IRP's - Requests in realtime on the hardware when that is needed.

Queues can contain requets or answers from hardware ... Answers are usually dispatched by the Kernel back to application at idle time (for example mouse input) or by IRQ's at realtime (for example the network input/output).

Generally put: "solved" requests from the queues come back to the applications as messages or callbacks depending on the realtime level requested. Some request might start at idle time but once fired it will contimue at realtime mode. Also some drivers might process data in realtime but send messages to application at a later idle time.

For example in SolarOS there is one such queue for:
-mouse (idle time)
-keyboard (idle time)
-floppy (realtime)
-network cards and IP stack(realtime)
And new ones are beeing added as we speak for:
-ATA hdd/CD-rom (realtime)
-USB UHCI devices (realtime)
-Sound cards(realtime)

As you can se things are very "simple" and clear

But all this above is not a standard... basically it is just my own concept and implementation generated by my mind on a simple analysis and from experience on many projects.

It all comes to my mind at "a blink of an eye" and I would never consider asking such architectural things to a human

You can eventually see from Solar OS that I do focus on realtime operations and I consider multitasking only at IRQ Kernel level and ignore user mode application multitasking as beeing "somehow irelevant" for me...

And indeed from a "drivers point of view" user mode applications are somehow irelevant since drivers do have a higher priority and they MUST deal with the hardware in realtime. Applications are just requesters and consumers for the work made by the drivers.

Of course "Your mileage might vary" depending on your experince and targets.

To "ease" the discussion level again ...

About humman race: I find myself acting and understanding and thinking in such very diferent ways compared with hummans... that I start to suspect that I am Alien Although beeing on Terra I do as hummans do... I am really amazed how they are not able to "see" and act as they do for thousands of years...

Actually, I got to the mentioned ideas myself, but the question is in the concrete asm-level implementation, i.e. I am in question of how to handle IRQs and how to treat drivers - as super-applications (processes/threads) or as a threadless/processless extension. And how to handle IRQs: send a message to queues of drivers, or simmulate interrupt on per-task/process/context basis for drivers which need it or simply allow a part of driver (handler_proc) to be called directly while in kernel IRQ interrupt handler code.

In a single-tasked environment it is as simple as 123: treat a driver as a threadless/processless extension/driver and handle IRQs by calling driver handler procedures directly, i.e. via CALL instruction in the kernel IRQ handler code. But multitasking env-t makes me feel frustrated.

Yes, I know you have after all it is elementary... Ideas are highly overestimated in this world. Actually ideas, start and ending worth nothing... it is only the path you are walking that matters.



Well, 2 options for you:
1)Code it!...
2)Check how I did it in SolarOS, how Windows does it, how Linux does, how MenuetOS does it, how BeOS does it... (add other OSes here) then again: code it!.



Again, just think of one way (the one you like most) and code it!. It will be the wrong way anyway . Check the advantages and the problems then re-iterate the process and again code it (hopefylly better this time)... and so on...

It is a commom missconception of hummans to think that they can design such things in advance. NO they can NOT!. Only God can (sometimes)... Hummans either test and experiment until they find the right way... or... they choose to lie about it.

To answer your question
Well, that has been answered in the above message anyway...but... eh hummans:

Drivers are to be considered Kernel parts with special rights and requirements... aka they can eventually be Loaded/Unloaded/Started/Stopped. Do NOT consider them as super applications. Drivers might or might not use threads inside kernel -->depending on your OS design... IMHO threads will slow things down a LOT and inside kernel they are an overkill...

But that is only my oppinion... you must experiment and find your own way... I can not walk the path for you...because then I will learn in your place (but i already know)... evolution is a personal bussines and most of the time it is agains of all other hummans and mostly against your own ego ...



That is a long phrase

Handle IRQs as fast as possible. Adding data to a queue (input)or processing an request phase (output). Also deal with variouse hardware needs as soon as possible (realtime).

Let another thread or process --or whatever YOUR design is-- handle the data in the queues and notify applications of events... but that is already MY design ... or pardon me everybody's design...

Applications can be notifyed by messages posted to application's window queue or by callbacks or IO completion ports... ouch excuse me but you already know all this...

IF you allow a user mode callback to be executed directly from an IRQ --> you are in big trouble and for a lot of reasons... I will let you enumerate them mentally...

Instead I sugest that only Kernel drivers/daemons should be able to eventually handle or establish such callbacks and only for speed-up resons.

In SolarOS some form of intermediate drivers receive those callbacks but they are under my strict control. Non-system applications receive notify callbacks at a later time.

I see no reason to "simulate" IRQs for per context basis ... other that maybe you have read some Windows documentation and miss-understod it a little.



I do not see how that is. Single tasking or multitasking user mode it has no relevance here. Because drivers are always multitasking no matter what.

This kind of "perfect" multitasking --as I call it it-- is because of IRQs that do a context switch exactly (almost) when the device requires it...

So you can not play single task "games" in an IRQ based system because the IRQ will switch context whenever it comes.

Ironically as it is you can somehow simulate a single task/process driver in a multitasking preemptive systems like Menuet. Some drivers in Menuet just act like they are alone there waiting in loops for hardware and rely on OS kernel to switch them out (to avoid busy waiting). This way the driver plays the game like it is the only application running... but I do predict that this will get them into trouble when drivers and arhitecture will evolve a little... besides it is also kind of slow.

I really do not see what else you can do in a IRQ handler but CALL the hardware driver handler procedure for it:D ... well you can just insert all the code there ...

But that is the whole ideea of an IRQ: to handle hardware requests... what else? play Go or chess? Of course things are not going to be that simple if you have multiple boards on the same IRQ and multiple drivers on the same IRQ... but that is just a logical expansion from the simple case.

I do not see how multitasking make you frustrated... can you bring multitasking to me so i can beat it because it makes you somehow frustrated? Strange powers it has upon you multitasking this is

I really suppose it is your MIND that generates your own mind frustration (for another part of the mind) because one part of you wants to design everything in advance without enough knowledge and without experimentation and trial...

When I was "humman" is used to call that manifestation: EGO or PRIDE... that is.

Go back to simple ways: experiment, seek simplicity not elegance, test again, reiterate and accept what it is... and above all: "very simple small steps"