need some help implementing messages to my kernel

[digo_rp]

guys I need to implement messages to use through process, I need to use like windows does. I need to use to give to applications mouse/keyboard event.

Could anyone give to me some tutorial with sources cuz I never saw before, I´m afaid I don´t know how to start.

sorry for my poor english.

[JamesM]

http://en.wikipedia.org/wiki/Message_passing

[AndrewAPrice]

guys I need to implement messages to use through process, I need to use like windows does. I need to use to give to applications mouse/keyboard event.

Could anyone give to me some tutorial with sources cuz I never saw before, I´m afaid I don´t know how to start.

sorry for my poor english.

Do you mean messages or events? My kernel distinguishes between the two, but this doesn't mean yours does.

In my kernel I've made a structure called an "event" containing 3 ints: Type, Action, Data.
Type - The type of event (keyboard, mouse, system, etc)
Action - The action which occured (key pressed, request program close, mouse key down)
Data - Any attached data (scan code (my console user library handles converting this to text), mouse button). This is optional (e.g. requesting a program close does not need data).

Each process has a linked list of events (new events get added to the end, requested events get taken from the beginning) that can be requested by the program through:
EventHandler::GetNextEvent(Event &e)
EventHandler::ClearEvents()
EventHandler::WaitForEvent(Event &e)

If there is no event and GetNextEvent is called, my kernel fills &e with a special No Event Recieved type.

Generally.. It isn't a good idea to send each mouse movement as an event unless an application specifically requests it wants to listen for them.

For "messages" (a. la inter-process communication), I send Type - System, Action - Event Received, Data - how big the message is. Then I have:

EventHandler::GetNextMessage(char *buffer, int size)
EventHandler::ClearMessages();

EventHandler::GetMessage(char *buffer, int size)
EventHandler::GetNextMessage();

The difference between GetNextMessage(char *, int) and GetMessage(char *, int) is GetMessage does not automatically delete the message after it has been read. This is so a large message can be read in multiple parts. GetNextMessage() (without parameters) simply deletes the current message after GetMessage is used.

Once you have assigned each process an ID, sending a string between them should be trivial - send a pointer to the message, the message length, and the PID destination to the kernel, and then attach the message to the process's linked list of messages and raise an EventRecieved message.

[JamesM]

I use a remote method invocation-based system of message passing. Essentially it's message passing, but with the index of a registered reciever function embedded in the message, which can be run like a POSIX signal handler. It works quite well!

Once you have assigned each process an ID, sending a string between them should be trivial - send a pointer to the message, the message length, and the PID destination to the kernel, and then attach the message to the process's linked list of messages and raise an EventRecieved message.

The main problem I see in IPC implementation is how to ensure a pointer given will be accessible between address-spaces? I.e. I call 'sendmessage' with a pointer to my local heap, how will the other process get it's contents? My answer is a general-purpose cross-address-space user heap. Like the kernel heap but user-writeable.

[AndrewAPrice]

I use a remote method invocation-based system of message passing. Essentially it's message passing, but with the index of a registered reciever function embedded in the message, which can be run like a POSIX signal handler. It works quite well!

Once you have assigned each process an ID, sending a string between them should be trivial - send a pointer to the message, the message length, and the PID destination to the kernel, and then attach the message to the process's linked list of messages and raise an EventRecieved message.

The main problem I see in IPC implementation is how to ensure a pointer given will be accessible between address-spaces? I.e. I call 'sendmessage' with a pointer to my local heap, how will the other process get it's contents? My answer is a general-purpose cross-address-space user heap. Like the kernel heap but user-writeable.

--To send a message:
In the sending program: Pass a pointer to the message to send to the kernel.
In the kernel: Copy the message from the the pointer (user-space) into kernel-space (I use a linked list of messages associated with each process)

--To receive a message:
In the receiving program: Pass a pointer to an empty location in memory to where to place the message.
In the kernel: Copy message from kernel-space to the pointer (user-space). (Then I remove the message from the process's linked-list of messages.)

This method assumes you know the size of the message. So the receiving program can either:
- Request the size of the message before it receives it so it can create a suitable buffer.
- Or, have a set message size, and receive the messages in chunks, along with a header indicating the current chunk, the total number of chunks, etc.