public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Alok Singh" <aloks@broadcom.com>
To: "Gary Thomas" <gary@mlbassoc.com>
Cc: <ecos-discuss@ecos.sourceware.org>
Subject: RE: [ECOS] Net BSD network stack posix tasks -
Date: Wed, 30 May 2007 15:42:00 -0000	[thread overview]
Message-ID: <FE7FB54DCB7C6949A1D3F9FF22DA6C135AB102@lvl7in-mail01.lvl7.com> (raw)
In-Reply-To: <465D6725.9010502@mlbassoc.com>

Gary,
    To give an example, I'm required to make a posix call in the
end_send function below. end_send will be called by the network stack to
send the out to Ethernet driver( layers below network layer to be
precise).  What will be happen in this case? Wouldn't the system crash
because of it??

ETH_DRV_SC(end_sc0,
    &end0_priv_data,    // Driver specific data
    ETH_NAME,           // Name for this interface
    end_start,
    end_stop,
    end_ioctl,
    end_can_send,
    end_send,
    end_recv,
    end_deliver,      
    end_poll,
    end_int_vector);

NETDEVTAB_ENTRY(end_netdev0,
    "device_end0",
    end_drv_init,
    &end_sc0);


*****************
end_send()
{
-------------------------------
  pthread_cleanup_push();
----------------------------

}


regards,
Alok

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com] 
Sent: Wednesday, May 30, 2007 5:30 PM
To: Alok Singh
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Net BSD network stack posix tasks -

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alok Singh wrote:
> Thanks for all the suggestions. My only issue is, and a simple one,
that
> if I want to send a packet out of the device in the network thread
> context, then I've problems. We have our implementation of message
> queues, mutexes, and other stuff that all use POSIX calls. So the code
> crashes, since I'm trying to make posix calls (while putting the
packet
> in the message queue, and using mutexes), in the context of native cyg
> thread context. To overcome this problem, I'm queuing the packet
coming
> out of the network stack, and then another posix thread de-queues the
> packet, and sends it out. This is working fine except that performance
> is not that good, and some fine tuning is required. In the limited
> testing I did while sending the packet out in the context of network
> thread, the performance is better, and suits my purpose.

Sorry, but this description doesn't make a lot of sense (to me at
least).
There should be no difference doing network I/O from a POSIX thread and
a native eCos thread.  Everything should boil down to socket I/O, which
is the API exported by the network stacks.

Perhaps you can explain in more detail, or provide some code snippets.
What do you mean by "send a packet out of the device in the network
thread
context?"

> 
> There is no issue with BSD stack. It runs perfectly fine.  
> 
> regards,
> Alok
> 
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Nick
> Garnett
> Sent: Tuesday, May 29, 2007 10:56 PM
> To: Alok Singh
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] Net BSD network stack posix tasks -
> 
> "Alok Singh" <aloks@broadcom.com> writes:
> 
>> Hi,
>> I don't understand licensing issues much. I've a question. Am I
> allowed
>> to convert network stack threads to posix threads instead of native
> cyg
>> threads?   I've compatibility issues making ecos network stack work
> with
>> my application (Posix based.) Though there are ways to overcome this
>> issue, but they affect the performance of the system.
> 
> (I'm not sure why this has anything to do with licensing.)
> 
> The network threads are internal to the stack. POSIX threads are for
> running application code. The network threads will never run
> application code and so don't need to be POSIX threads. The network
> threads work perfectly well alongside POSIX applications without
> needing to be POSIX threads themselves.
> 
> I don't know what problems you are having, but your suggestion is
> almost certainly the wrong solution. It sounds to me like you are
> trying to do something that eCos doesn't support. Tell us what the
> problem is and maybe someone can offer a better solution.
> 
> 


- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGXWckmaKbSsQGV8ARAr3GAKCCnOVJk6HLJcYN9wLLJSVzJLAOlgCgqeUN
+tgYjbY2PUR/MndJIzNO3GM=
=K/bm
-----END PGP SIGNATURE-----



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

  reply	other threads:[~2007-05-30 15:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29 17:11 Alok Singh
2007-05-29 17:20 ` Gary Thomas
2007-05-29 17:26 ` Robin Randhawa
2007-05-30  0:00 ` Nick Garnett
2007-05-30 11:59   ` Alok Singh
2007-05-30 13:07     ` Gary Thomas
2007-05-30 15:42       ` Alok Singh [this message]
2007-05-30 15:56         ` Gary Thomas
2007-05-30 16:33           ` Andrew Lunn
2007-05-30 17:53             ` Alok Singh
2007-05-30 18:14               ` Andrew Lunn

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=FE7FB54DCB7C6949A1D3F9FF22DA6C135AB102@lvl7in-mail01.lvl7.com \
    --to=aloks@broadcom.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=gary@mlbassoc.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).