public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Mohammed Illyas Mansoor <mansoor@cdotb.ernet.in>
To: bartv@cygnus.co.uk
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] Serial device driver for linux synthetic target!
Date: Tue, 05 Oct 1999 08:10:00 -0000	[thread overview]
Message-ID: <37F9C7D7.665CCA26@cdotb.ernet.in> (raw)
In-Reply-To: <199910051316.OAA06305@sheesh.cygnus.co.uk>

Bart Veer wrote:

> Within Cygnus we have been thinking along slightly different lines,
> but nothing has been implemented yet. The basic idea involved having
> the synthetic target application talking over a pipe to an external
> multiplexer process (possibly a program, possibly a Tcl script running
> in a suitable interpreter, whatever).

            This would require a protocol between the pseudo_dev and the
multiplexer process as to which actual dev it wants to talk to for eg., lcd,
serial-dev or say a socket, also how this device would interact with the
eCos applications is also not very clear, as to how it would handle an
application requesting to open say /dev/ttyS0, probably it should be a
catch all device-driver, all this seems a bit complex to me.

          What I am aiming is to have an eCos application which was written to

talk with the serial-device on the actual-hardware,  should be able to run
on the linux synthetic target also, without any modification whatsoever, for
this a pseudo-serial device driver for linux would be sufficient just like for

all other archs. ie., having i386 directory in io/serial/current/src and in
that
a sub-dir called linux or sim (presently) later when eCos supports actual i386

target, the device driver would be written  in i386 directory.

        The actual aim of this synthetic device driver is to help me test
TCP/IP stack which I am planning to port, using the SLIP driver with a linux
box
attached on the other end running SLIP.

> The device-specific application could also send data back to the eCos
> application. This would arrive on the pipe, causing a SIGIO signal to
> be raised. The synthetic target's interrupt handling support would be
> rewritten around SIGIO.
>

    This is what extactly I was having in my mind also.

>
> Obviously there are plenty of details to be resolved, but this would
> be a very powerful extension to the synthetic target support.
>

    This pseudo-device would really be a nice thing to have in the synthetic
target, if the device driver handles all the details with respect to the
multiplexer
process transparent to the eCos application thread.


--With Regards,

M. I. Mansoor

  parent reply	other threads:[~1999-10-05  8:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-05  3:31 Mohammed Illyas Mansoor
1999-10-05  6:16 ` [ECOS] " Bart Veer
1999-10-05  7:01   ` William Gatliff
1999-10-05  8:10   ` Mohammed Illyas Mansoor [this message]
1999-10-05 11:59     ` Bart Veer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37F9C7D7.665CCA26@cdotb.ernet.in \
    --to=mansoor@cdotb.ernet.in \
    --cc=bartv@cygnus.co.uk \
    --cc=ecos-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).