Removed all old object/request/... stuff (that was crap)

6 files changed, 80 insertions, 136 deletions

diff --git a/doc/manager.txt b/doc/manager.txt
deleted file mode 100644
index 5603ee5..0000000
--- a/doc/manager.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-The manager is a service whose role is to manage all other services. By default, all loaded modules
-get a descriptor to the manager service (descriptor 1).
-
-Each service has a set of ressources that can get a descriptor by openning them. These ressources
-are identified by a string, such as :
-kbd:readtext
-file:root/System/
-console:myuser/main
-
-To open these objects, a process would call the open() method on the manager object. The manager would
-then call the open() method on the corresponding process with the string after the first semicolon
-(for example: open("file:root/System") would call file.open("root/System")).
-
-If the string is just a service name (like open("kbd")), the manager would return a descriptor to the
-root object for that service.
-
-The manager is also the one that handle log entries for services, for the moment by printing them on the screen.
diff --git a/doc/messaging.txt b/doc/messaging.txt
new file mode 100644
index 0000000..804bb5d
--- /dev/null
+++ b/doc/messaging.txt
@@ -0,0 +1,48 @@
+Message passing is the technique used by processes for communicating with each other.
+It is based on a few basic functions :
+
+= msg_register =
+Registers the current process as the owner of a system channel.
+System channels are aliases for PIDs (negative PIDs resolve to corresponding real PID).
+They range from -1 to -255. They are allocated as follows :
+ from -1 to -19 : drivers
+   -1 = keyboard
+   -2 = mouse
+ from -20 to -29 : network services
+   -20 = networking subsystem (may be in several parts)
+ from -30 to -39 : system services
+   -30 = virtual file system
+   -31 = logger
+   -32 = user server
+ from -40 to -49 : UI services
+   -40 = graphic server (includes VESA driver for now)
+   -41 = sound server
+Modules for HDD drivers, network cards, sound cards, ... do not register as devices but instead
+notify of their presence to the corresponding service.
+
+= msg_send =
+Sends a message to a process. Arguments:
+- Receiver PID or system channel id
+- Message data (up to 64k bytes, minimum 4 bytes)
+The first 4 bytes of the message data always designate the message code (function).
+The kernel may intercept some special messages (as "kill process" or stuff like that).
+
+= msg_info =
+Gets first message in the queue for current process.
+Function can block waiting for a message if asked by caller and if no other function already does it.
+When it is there, return the following:
+- If a message has come
+- The sender PID
+- The message code (first 4 bytes of data)
+- The length of the data
+
+= msg_get =
+Reads the data of the first message in the queue for current process.
+Is passed a pointer where the data will be written. It is supposed that enougth memory is already allocated.
+
+From a kernel point of view, message passing is asynchronious,
+but there also are userland functions for making them look synchronious by waiting for an answer.
+Usually, message codes | 0x80000000 are answers to a message.
+
+Most processes, most of the time, will be in a loop waiting for messages to come.
+The drivers are the principal exception to that, they instead wait for an interrupt or another hardware signal.
diff --git a/doc/method.txt b/doc/method.txt
deleted file mode 100644
index 066e0ae..0000000
--- a/doc/method.txt
+++ /dev/null
@@ -1 +0,0 @@
-All methods are defined in src/include/gm/method.h and src/include/gm/m/*
diff --git a/doc/objects-requests.txt b/doc/objects-requests.txt
deleted file mode 100644
index e53c343..0000000
--- a/doc/objects-requests.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-The requests can be of two types :
-- Blocking, IE the sender waits for an answer
-- Nonblocking, the request is a simple message.
-
-Requests are identified by a 32bit function number, composed as follows :
-    (8 bit) parameter and return type ; (24bit) function number
-
-the first 8 bits are :
-	2bit answer type ; 2bit parameter a type ; 2bit parameter b type ; 2bit parameter c type
-
-each two bit couple can be one of the following :
-- 00 : void
-- 01 : object descriptor number (will be copied with a new number to reciever)
-- 10 : long
-- 11 : long long (replies), or shared memory offset in sender's space (requests and messages)
-
-When shared memory segments are sent as request parameters from a process to the same process, the pointer
-to the memory is kept and sent to the handler function. If handler is in another process, receiver will
-have to call request_mapShm specifying a pointer. Shared memory is automatically unmapped when requests
-yields an answer, and is kept when the request is nonblocking (message).
-
-When objects are sent as request parameters, the receiver process will get an immediately usable object
-descriptor. The descriptor is closed in blocking requests after the request yields an answer (except if the
-request is handled in the same process than the sender, OR if the receiver already had a descriptor to
-this object). The descriptor is kept when sent by a nonblocking request (message).
diff --git a/doc/roadmap.txt b/doc/roadmap.txt
index 14003c0..cf14395 100644
--- a/doc/roadmap.txt
+++ b/doc/roadmap.txt
@@ -7,5 +7,5 @@
 **		0.0.5 'Truth is better cold'		**
 - Review privilege system
 - Driver processes can ask to map physical memory in their address space
-- Describe interfaces for server (any service's main object), reader and writer.
-- Keyboard driver, userland display driver, virtual terminal driver
+- Redo all messaging stuff, simpler.
+- Keyboard driver, veryveryvery simple shell module using kbd driver and printk
diff --git a/doc/syscalls.txt b/doc/syscalls.txt
index 8053b38..28eb636 100644
--- a/doc/syscalls.txt
+++ b/doc/syscalls.txt
@@ -14,100 +14,39 @@ id=eax	Name			Parameters				Description
 						edx: stack pointer
   6		irq_wait		ebx: irq number			Waits for an IRQ (requires privilege PL_DRIVER)
   7		proc_priv		none					Returns current process privilege level
-  8		shm_create		ebx: offset				Create a shared memory segment at offset (ret = errcode)
+  8		proc_setheap
+  9		shm_create		ebx: offset				Create a shared memory segment at offset (ret = errcode)
 						ecx: length
-  9		shm_delete		ebx: offset				Delete a shared memory segment at offset (ret = errcode)
-  10	object_create	none					Creates an object for current process (returns a descriptor to it)
-  11	object_owned	ebx: object descriptor	True (1) if object with this descriptor is ours, false(0) elsewhere
-  12	object_close	ebx: object descriptor	Closes descriptor to an object (deleting it if necessary)
-  13	request_get		ebx: object descriptor	Gets a request pending on object (only if we own it)
-						ecx: pointer to write request
-						edx: wait for a request ?
-  14	request_has		ebx: object descriptor	Is there a request waiting on this object ?
-  15	request_answer	ebx: object descriptor
-						ecx, edx: answer		Answer a request on object
-  16	request_mapShm	ebx: object descriptor	Map shared memory sent with request to receiver's address space
-						ecx: offset
-						edx: parameter number (0, 1 or 2)
-  17	request			ebx: object descriptor	Send a blocking request to object
-						ecx: pointer to user_sendrequest struct with information
-  18	send_msg		same as above			Send a nonblocking request to object, same as above
-  19	proc_setheap	ebx: start address		Creates/resizes/moves the heap segment allocated to this process (one per process)
-						ecx: end address
+  10	shm_delete		ebx: offset				Delete a shared memory segment at offset (ret = errcode)
+  11	msg_register	ebx: service id			Registers current process as owner of a system channel (ret = errcode)
+  12	msg_send		ebx: receiver pid		Sends a message to pid or owner of system channel
+  						ecx: message data ptr
+						edx: message length
+  13	msg_info		ebx: answer struct ptr	Get info on the first message of the queue for this process
+  						ecx: wait?
+  14	msg_get			ebx: pointer to data	Gets the data for first message on the queue; deletes message from queue
+
 
 If a processes wishes to exit with an error code, it HAS to use process_exit. thread_exit will do nothing.
 
 ====== SYSCALL DESCRIPTION ======
 
-= object_create (10)
-Parameters: none
-Returns: descriptor to created object, 0 if failure (should not happen)
-Creates an object belonging to current proces.
-
-= object_owned (11)
-Parameters: an object descriptor
-Returns:
-- 1 if object belongs to current process
-- 0 if object does not belong to current process
-- -10 if descriptor does not exist
-
-= object_close (12)
-Parameters: an object descriptor
-Returns: nothing
-Closes a given descriptor to an object. If descriptor does not exist, call is ignored.
-
-= request_get (13)
-Parameters: an object descriptor, a pointer to a location to write request, a boolean : wait for a request?
-Returns:
-- -10 if descriptor does not exist
-- -2 if object is not possesed by current process
-- -3 if a blocking request is currently being processed
-- -1 if no request is pending and [wait] is not set
-- 0 if a request was written to location (call successful)
-Fetches a waiting request or message on object, and deletes it or acknowledge it.
-
-= request_has (14)
-Parameters: an object descriptor
-Returns:
-- -10 if descriptor does not exist
-- -2 if object is not possesed by current process
-- 0 if no request is pending
-- 1 if a waiting request is there
-- 2 if a request is being processed
-
-= request_answer (15)
-Parameters: an object descriptor, two ints forming a long long if necessary, an int which is the return status (error code) of the function
-Returns: nothing
-Answers a request marked as currently being processed, ignoring cases where :
-- descriptor does not exist
-- object does not belong to process
-- no request was being processed
-
-= request_mapShm (16)
-Parameters: [id] object descriptor, [pos] pointer to a location, [number] int
-Returns:
-- -9 if [number] < 0 or [number] > 2
-- -10 if descriptor does not exist
-- -2 if object is not possesed by current process
-- -3 if no request is being processed
-- -4 if there is usually no shared memory in parameter [number]
-- -7 if sender process is receiver process, in which case memory is already mapped somewhere
-- -5 if no shared memory was sent by this parameter
-- 0 if shared memory in parameter [number] of currently processed request of object [id] was mapped at [pos]
-
-= request (17)
-Parameters: [id] object descriptor, [pos] pointer to request data
-Returns:
-- -1 if an unknown error happened (should not happen)
-- -10 if descriptor does not exist
-- -11 if objet cannot handle requests
-- -2 if request was interrupted
-- 0 if request was handled and result written in [pos]->answer
-
-= send_msg (18)
-Parameters: [id] object descriptor, [pos] pointer to request data
-Returns:
-- -1 if an unknown error happened (should not happen)
-- -10 if descriptor does not exist
-- -11 if object cannot handle requests
-- 0 if nonblocking message was sent
+= msg_register (10)
+Parameters: requested system channel id (int)
+Returns: errorcode or 0 on success
+Registers current process as owner of given system channel.
+
+= msg_send (11)
+Parameters: receiver pid (signed! int), data ptr (void*), data len (unsigned)
+Returns: errorcode or 0 on success
+Sends a message to given PID or owner of given system channel.
+
+= msg_info (12)
+Parameters: pointer to answer struct (msg_info_answer*), wait for request? (bool)
+Returns: nothing (all is in answer struct)
+Gets info on waiting messages for current process.
+
+= msg_get (13)
+Parameters: pointer to data struct (void*)
+Returns: errorcode or 0 on failure
+Gets the data for a message that is in the queue.