Re: [ECOS] Update on the availability of socketpair()?

[Nick Garnett <nickg at ecoscentric dot com>]

Andrew Lunn <andrew@lunn.ch> writes:

> On Wed, Jan 21, 2004 at 03:28:20PM -0600, Philip.Fleege@gd-ais.com wrote:
> > Hi All-
> > 
> 
> > I read in an earlier posting;
> > http://sources.redhat.com/ml/ecos-discuss/2003-07/msg00485.html that
> > the function: socketpair() was intentionally left out of the 2.0
> > release.  But that it could (and therefore might) be added.  Is
> > there any short term (or long term) plan to add this call?
> 
> Not that i know of. Nobody has contributed patchs as far as i know.
> 
> > Just as is described in the reference above, I'm porting some unix
> > code that uses a "tickle" pipe to wakeup a thread blocking on
> > select().  And yes, I could use a 'localhost' socket.  However, I am
> > advocating that socketpair() be added since it makes the application
> > code so simple and elegant.
> 
> If you want it, then i suggest you implement it (or contract somebody
> to do it for you). It should not be too difficult. 
> 
> > Finally, if there is an effort to add this to eCos, what is the
> > chances that it could be kept in without having to have all the
> > network code; or it be a "configurable" item.  I guess what I'm
> > really asking is what are the chances that a pipe() system call be
> > added.  Our embedded application will actually be using serial
> > lines...but we use the network during development (to fake out
> > devices) so our final software will not have a network stack (thus
> > no socketpair() when we remove network support).
> 
> The current socket interface has a plugin architecture. There is a
> generic socket layer which different stacks register there
> implementations of socket functions to. You should implement your code
> as a little stack which registers itself and only implements AF_LOCAL
> socketpair(). You will need to extend the socket interface a little
> since it currently does not have socketpair(), but that should not be
> too hard.  With this architecture it should be easy to make it run
> with and without the AF_INET TCP/IP stack.

Everything Andrew says is true. My own thoughts on the issue:

- I was perhaps being a little over-optimistic when I suggested before
  that it might be easy to add socketpair() back to the TCP/IP
  stack. The entire AF_INET family code has not been ported, the only
  way to do it in the current stack would be to generate a pair of
  back-to-back TCP sockets, but they would end up doing the full TCP
  protocol through the loopback interface. Not nice, but it would
  probably work.

- In BSD pipe() is really just a wrapper for socketpair(), so there is
  no pipe implementation we could import. Writing a pipe
  implementation from scratch, and getting it to work correctly in all
  situations is not an afternoon's job. It also raises all sorts of
  issues about memory allocation and dynamic buffer management which
  we would prefer to avoid.

- The main requirement here is to kick a select() out of its wait. So
  one option is to implement a simple "semaphore" filesystem. This
  allows named "files" to be created and opened. Writes to the file
  increment a counter, reads decrement it, selects wait until the
  counter is greater than zero. No data is transferred or stored, so
  there is no memory allocation issue. Something like this could
  probably be tinkered together fairly quickly.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss