Andrew, The issue I reported yesterday about bsd_accept was an issue on my old snapshot. The latest version of bsd_accept is good to go. I am using an older eCos snapshot because of the modifications I had to make for my processors/platforms being used that aren't supported by eCos and my lack of free time to merge all of these changes in to the latest snapshot. I am currently going to be using the latest eCos for the MPC85xx processor. A&M has a port for their Python board (MPC8541) but it hasn't been applied?
As for the zpool, a couple/few years ago there was a thread regarding the lack of locking and they added a mutex that was used to prevent pre-emption inside of zalloci and zfreei. Rick -----Original Message----- From: Andrew Lunn [mailto:[EMAIL PROTECTED] Sent: Saturday, September 01, 2007 6:39 AM To: John Mills Cc: eCos Users; Rick Davis Subject: Re: [ECOS] network problem Hi Folks I've lost track of the different threads about memory leaks in the network stack. It seems like one of the leaks being talked about here was fixed a long time ago: 2003-07-28 Jay Foster <[EMAIL PROTECTED]> * src/sys/kern/sockio.c: Fixed memory leak in accept() call. Do we still need locking in socreate()? socreate calls soalloc. That has a comment /* XXX race condition for reentrant kernel */. The actual problem is in zalloci which does not perform locking on the linked list of elements in the pool. We are re-entrant? socreate() is only called from bsd_socket(). bsd_socket() should only be called from socket(). socket() performs locking, depending on what synchronisation protocol is in use. bsd_tcpip has no synchronisation protocol, so two simultaneous calls to socket() could result in a race! Could somebody please submit a full patch for socreate. Are there any other issues left? Thanks Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
