From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: OT: Mach Ports (For the AdaOS folks) References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 30 Dec 2004 14:06:14 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1104433511 24.150.168.167 (Thu, 30 Dec 2004 14:05:11 EST) NNTP-Posting-Date: Thu, 30 Dec 2004 14:05:11 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:7336 Date: 2004-12-30T14:06:14-05:00 List-Id: Dennis Lee Bieber wrote: > On Thu, 30 Dec 2004 11:30:35 -0500, "Warren W. Gay VE3WWG" > declaimed the following in comp.lang.ada: >>However, IMHO, the microkernel should be small as possible, and >>leave networking up to the modules outside of it. After all, some may >>perfer an IPv6 only version of networking for example (in light >>of China's recent network announcment). In the end, I don't want >>to be "stuck" with what a brand of microkernel gives me. Just >>give me the basics and let me decide what is included. > Pardon my slipping in, but... Discussion is always welcome here. > The more I read in this thread, the more it sounds like my old > Amiga. I believe however, there is at least one major difference ;-) > The Amiga EXEC handled only a very small list of functions: > memory management (the weak point for the Amiga -- flat, shared, memory > space; no process protection), This _is_ the major difference. Mach, L4 and other microkernels provide memory management for you, such that the mk itself, which is kept very small, is the only piece that runs in "real mode". All other modules run in user-mode, preventing security breaches and corruption from programming errors. Part of the idea is to keep "real-mode code" to a minimum. > task scheduling (including > semaphore/signal stuff) and process creation, shared library loading > (note: not the I/O to load the library into memory, but rather the > linking of a library into system lists), and IPC (message ports: > essentially linked-lists on which a task may insert a "message" -- a > structure with a pointer to the task specific data structure; this is > why the flat memory model was pretty much needed). > > All I/O, including keyboard/display, relied upon > libraries/device drivers which had to be loaded (yes, it sounds > chicken&egg here -- the Amiga ROMs did contain more than just EXEC, to > include the core file system handlers, device drivers, etc. but they > were logically independent units and could be replaced at run-time by > libraries with identical interfaces). > > Everything was done via message ports... An application disk > read request became a message to the file handler, which then generated > a message for the disk device driver, etc... I find that the Mach message interface to be especially convenient. I think that this one Mach concept is perhaps the most brilliant part of that work. Now, one might wonder how a Mach message queue (essentially that is what it is within the kernel) differs from a UNIX (SysV IPC) message queue? The differences include the following: SysV IPC Message Queue Mach =============================== ================================= - can have multiple receivers - only 1 receiving port per queue (hence only 1 receiver) - can have multiple senders - same - does not have a send-once - supports a send-once "right" - access is limited only by - you must be "given" a right IPC permissions (or must have access to the "task" port that you are going to acquire a "right") - Can configure how much a - In Mach, I think you can queue can hold configure between 1-12 "message backlog" - Not supported - Can force one message (only) if a queue is full - Not supported - Dead port notification (when there are no receivers) - The IPC "queue" is removed - Only the "receiver" port is destroyed to destroy the queue - Messages can be prioritized - No priorities : FIFO What makes Mach's port mechanism secure is that you cannot send to a port, unless you are _given_ a "send-right" (as send-only port to the message queue). There is one exception WRT the ownership of a task port (see below). In essence, there can only be _one_ "receive" right - ie. only one task can own this receive-right (aka port) (a "task" in Mach, is the address space, with or without threads). You cannot duplicate a receive right, but you can "move" it to another task, by "sending" it to another task, on another message queue. A send-right OTOH, can be duplicated as often as you like (it only increments the send reference count on the queue). A send-once right works the same way, except that you can only use that port to obviously send a message once (all other duplicated send-once rights become dead ports, after the message is sent on any of them, IIRC). So how does task B get a send right to a port in task A? It must have a send-right delivered to task B, by a message. But there is a bit of a chicken and egg problem here. To solve that, typically, one module serves as a "name server". When task B is created by the parent task, a send-right is "inserted into task B". This allows it to query the name server; to acquire a send right to A (provided that A has registered a send right in the name server under some agreed upon key). The name server duplicates the registered send-right and "moves" it by message to the caller (client). The "exception" that I refered to above is this: The parent "task" receives a send-right of the child task it creates. As the parent task, it is free to insert ports or to remove ports, as long as it holds a send-right to that child task's task port (by which other operating system calls are possible). Once the parent task closes the child-task's task port (send-right), it then cannot meddle any further (it cannot insert/remove any further ports etc.). So the bootstrap process might make the first "task" (module) the name server. All other bootstrapped modules would have a send-right inserted into it, which allows them to contact the name server. The name server acts as a runtime registry to accept registrations of services and allows clients to query and obtain send-rights to these services. What's neat about this is that it is secure. Knowing a port number in task A as 87, is of no use to task B. The port numbers are local to the task, so there is no global ID that can be used to access the port (service). A send-right in A as 87, might be 63 in task B, and 45 in task C. The port numbers are only for local task use. This is one of the problems that the L4 mk has, since its port IDs are global and can be guessed/determined. Knowing the ID in L4, gains you access enough to send messages. I should explain the send-once right: sometimes you want some follow-up notification, but you only expect one message. A send-once right guarantees this. This helps the receiver as well as other possible sources of the send-once (they all become dead-ports, once someone uses it to send a message). Thus, a send-once right guarantees that only one message is queued, and at the same time, notifies all other cloned send-once rights that they are now dead (and thus are no longer needed). Mach 3.x dispensed with a complicated "ownership-right", which existed in addition to the receiver port in earlier releases. I assume that the Mach designers eventually came to the conclusion that it was a concept that was redundant. Certainly with its removal, the port concepts become simpler (now when a receive right is destroyed, all send-rights become dead ports, notifying all clients of a service, that the service is now "offline"). Anyway, if you want a deeper understanding of all this good stuff, there is a book you can get used that does an excellent job at describing Mach concepts (ports, tasks, threads and memory objects): Programming Under Mach: http://www.amazon.com/exec/obidos/tg/detail/-/0201527391/103-1295179-1094257?v=glance Unfortunately, it does centre on Mach 2.5, but mentions Mach 3.x changes (it will cover the important 3.x features). You will also have to overlook a certain amount of "UNIX doesn't have threads" discussion, since it was published in 1992. Otherwise, this is a recommended read for anyone who is contemplating messing with microkernels, particularly of the Mach variety. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg