[ECOS] Thoughts of semaphore filesystem device to would behave like socketpair() and/or pipe().

[Philip dot Fleege at gd-ais dot com]

Hi Nick(all)-

Thanks for the quick responses....

Ok, I like the idea of creating a special "semaphore" filesystem.  My background brings me here with more from the applications development and thus the posix layer...not much driver experience; but always wanting to learn.  So we may want to persue this. For now, I have the work around completed; using two full blown INET sockets via 'localhost'...yuck!

Although, your assertion that the primary requirement is to unblock select() is true, in addition we need to use the "tickle" file descriptor (that the target thread is select()ing on), to pass control data, i.e. we send about 32 bytes of "command/context" data so the target threads knows 'why' it is being unblocked (not just that he needs to unblock).  Therefore, the ideal solution would look something like a pipe where this command data could reside with the device until it is read by the one target thread (the one blocking on select()).

You had indicated that having data buffered within this device is not optimal; and I understand why.  However, if we could have this and have it configurable, this could be a very powerful device (realative to the specific use case described above).  In this way, client threads (threads writing to the 'tickle' device) could write their command data without blocking (until the device buffer is full; or returns with errno set to EWOULDBLOCK if the write side is configured as non-blocking and the buffer is full).

The buffer size configuration could be defaulted to zero; for those who do not need to send data and/or who do not want to pay the price for the allocation/space.  This configuration could be a 'static' ecos.ecc/package config option.   Going for the "dream solution", a special ioctl() command could be defined that would allow dynamic runtime modification of this buffer size.  This would be useful for those occations where several instances of this device are created/realized but each use has a different size requirement.

By the way, I would like to be able to allocate a non-predetermined number of these devices.  In otherwords, like pipe() or socketpair(), I need to be able to open multiple instances of this type of device...up to the max allowed file descriptors.  Each open()'ed instance has it's own semaphore count and optional data buffer.

Again, I haven't begun to look into the implementation details of an eCos driver.  I've been working at getting our linux/vxworks code ported... I'm not sure if what I have outlined above is reasonalable or even do-able... but I tried to better clarify our needs.

Does this sound reasonable to you?  If so, would this be something that the eCos community would support development on.  In otherwords, I'm not sure how things get done...I'm not sure if you would want me doing it...or when I would(or could ever) get it done.  If I were to attempt this, would it be something that you (or the eCos community) would help support me on doing?

Thoughts?
Phil

-----Original Message-----
From: Fleege, Philip T
To: 'ecos-discuss@sources.redhat.com'
Cc: Fleege, Philip T
Sent: 1/21/2004 4:28 PM
Subject: Update on the availability of socketpair()?

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?

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.

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).

Thanks for the update in advance!!!
Phil

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