This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pipe Library

On Fri, Dec 24, 2004 at 11:28:38AM -0700, Cameron Taylor wrote:
> We have developed a pipe implementation which we find useful for
> interprocess communication. It is also the basis for the pty implementation
> in the following submission.
> As seems appropriate for an embedded system, pipes are instantiated
> statically. The same mechanism is used as for other devices: an entry is
> made in the DEVTAB for each pipe the application wishes to use. An arbitrary
> number of pipes can be created. The application then uses open(), write(),
> read(), select(), etc. to access the pipe. Both read and write selects are
> supported.
> One option implemented is a timeout applied to reads and writes set on
> instantiation: FOREVER, NO_WAIT or a timeout in ticks (this is separate from
> the select timeout).
> The pipe can also be purged (pipelib_purge just calls fsync which discards
> any content).
> We have inserted the attached files in packages/io/pipe/... and made the
> following entry in ecos.db
>     alias        { "Pipe Driver Library"}
>     directory    io/pipe
>     script       pipelib.cdl
>     description  "This package contains a device driver for pipes."
> }

I've taken a very brief look, not looking at the sources in
details. These are just the things that jump out at me now. Im sure
there will be other comments when i take a deeper look.

I would drop the reference to lib everythere. The whole of eCos is a
library, so a library inside a library does not make much sense.

I would also remove pipelib_purge. You have the functionaly via
cyg_set_config() so there is no need to duplicate it.

Where possible you should try to use the device driver API, not the
kernel API. I think it should be simple to change this. See 

and the pages before. The advantage of using the driver API is that it
always exists. You can configure eCos without the kernel and your code
then fails. If you absolutely must use the KAPI, you need to add a
requires statement to your CDL so that it gets disabled when the
kernel is not present.

The timeouts are interesting, but are not normal for POSIX FIFOs. I
would be tempted to add CDL to control the compilation of this and
have it disabled by default. On the flip side you might want to make
the block on opening the name pipe more Unix like. ie if you open it
for writing it will block until some other thread opens the device for
writing. See

Some of the copyright statements need cleaning up. Any totally new
files just need copyright eCosCentric Ltd. You cannot keep your own
copyright statements, but please feel free to put a company name etc
in the authors/contributers field.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]