Re: [ANNOUNCE] Introducing Codezero

[Bas Wijnen]

Hi,

On Sat, Jul 04, 2009 at 01:40:03AM +0200, Ludovic Courtès wrote:
> > One could have "ctl" and "data" files as in Plan 9, to implement
> > driver control and data flow (or use extensible file attributes)
> >
> > File-based API should work for most services such as communication
> > protocols, drivers, console etc. Please elaborate on why you oppose it.
> 
> I suppose Bas is referring to the fact that Plan 9 ends up doing a lot
> of possibly costly marshalling/unmarshalling on `ctl' nodes (see [0] for
> an example).

I don't really know much about Plan 9, so this isn't what I meant.
However, I had heard this and don't like that either.  But it's not an
essential part of the "all communication is done on file-style objects"
idea.

What I meant is that there are at least two major modes of
communication.  One is stream-based and is used for files and tcp/ip,
for example.  When writing or reading, a sent package may end up as two
received packets and vice versa.

The other mode is with packets.  Udp/ip uses this, and so do most device
drivers.  For files, something similar is possible when using mmap.  For
general communication between threads, I would expect this to be the
main mode, in fact.  As a comparison, in the usb protocol, there is:
- interrupt and control traffic: packet-based, small chunks.
- bulk traffic: packet-based, but often interpreted as a stream.  Larger
  chunks.
- isochronous traffic: stream based.  (Like tcp/ip, the underlying
  protocol uses packets, but packet boundaries need not be preserved.)
  Relatively huge throughput.

Using these terms for ipc, I think most communication channels would be
control traffic, sending each other command messages and replies.
When using a stream where you cannot be sure that an entire command is
transmitted in one packet, you will need to do buffering and checking,
only executing the command when it is completely received.  Given the
amount of communication in a microkernel-design, I expect this to be a
major cost.  I would therefore always require comands to be sent in one
go, and provide a guarantee that packet boundaries are preserved (or at
least never created by the transport layer)[0].  Of course, this does not
require a redesign of the system, and you may well have these
requirements already in your definition of file.

On the other hand, using packet-based communication for everything isn't
such a good idea either.  While most device driver and other "control"
traffic is normally in packets, much data traffic is not.  So you would
need to add all the buffering stuff for every stream in the system.  Now
I think there's not much you can do about that.  A stream does not have
a limited size, and new data can keep coming in.  If the kernel would
support it as a stream, it would need to do the buffering itself.  I
don't think I've ever seen an idea to organize streams, which was not
based on packets underneath.  However, in streams it is acceptable to do
partial operations ("half of the data was successfully written, please
retry the rest"), or merge two packets into one.  As I wrote above,
those operations cost a lot when both sides of the communication really
want to be looking at packets.

I conclude therefore, that packets and streams are two separate forms of
communication, and that both have their own uses.  Using one system for
both types cannot give you maximum performance.  And with a microkernel
system, you need maximum performance when it comes to IPC, because it
happens so much.

Finally, a note about networking: with ip, there is a stream and a
packet-based protocol (tcp and udp).  However, udp also implies
"unreliable": the order of packets may change, and packets may be lost.
This has great advantages for the routing hardware.  I don't think it's
useful to have anything like that for communication within one computer,
but it can be considered.

Thanks,
Bas

[0] While the usb protocol does indeed send packets, and they are often
    used as such by the hardware connected to a port, Linux actually
    treats interrupt traffic as a stream.  This means that I need to add
    buffering code to my firmware when I write a USB device.  IMO this
    is a design flaw in Linux.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html

signature.asc
Description: Digital signature