diff options
Diffstat (limited to 'hurd')
-rw-r--r-- | hurd/libchannel.mdwn | 62 |
1 files changed, 62 insertions, 0 deletions
diff --git a/hurd/libchannel.mdwn b/hurd/libchannel.mdwn new file mode 100644 index 00000000..d3dff162 --- /dev/null +++ b/hurd/libchannel.mdwn @@ -0,0 +1,62 @@ +[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] + +[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU_Free_Documentation_License|/fdl]]."]]"""]] + +# libchannel + +*libchannel* was accepted as a project for [[Google_Summer_of_Code|community/gsoc]] (or +just GSoC) in 2007. It was written by Carl Fredrik Hammar who was mentored by +Richard Braun. + + +## Outline + +*libchannel* was intended to be used to cleanly and efficiently +implement *channel* translators that would correspond to character +device files. In other words, translators for input devices, sound, +network and the like. + +There are many cases where one wishes to stack translators over one +another. Take networking as an example, you may wish to have a pseudo +network device that balance traffic over two real devices. + +The problem with stacking translators this way is that it's +inefficient, for every RPC to the balancer a RPC is made to each of +the real devices. Now a RPC isn't really *that* expensive, but in a +more complex example with more layers the overhead of these RPC's makes +such a stacking infeasible. + +However, by using *libchannel* a translator can provide a description +of what it does (i.e. the code and data it uses), which a translator +layered untop can fetch and use directly. Now only strictly required +RPC's needs to be sent. + + +## Result + +By the end of GSoC 2007, *libchannel* had mostly reached the initial +goals. There some code missing, most notably the code for +transferring channels via RPC, but similar code was already present in +*libstore* and can be trivially adapted for *libchannel*. It also +needed more debugging. + +Despite these minor deficiencies, the project was considered a +success, never the less. + + +## Future directions + +However, while *libchannel* matched the original specifications. It's +believed that it's too inflexible to make use of in many specific +cases and that a more general solution is desired. While the +discussion isn't over yet, it seems *libchannel* will become a support +library to implement specialized channel libraries, e.g. *libaudio* +and *libnetwork* or similar. + +So work on *libchannel* will continue, in one form or another. |