[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] [bug #40245] unix port minimal project has abundant tim

From: Sylvain Rochet
Subject: Re: [lwip-devel] [bug #40245] unix port minimal project has abundant timers
Date: Sun, 22 Feb 2015 21:17:31 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hello Simon,

On Sun, Feb 22, 2015 at 08:59:17PM +0100, address@hidden wrote:
> Sylvain Rochet wrote:
> >Yes, it is simpler but it does not add any new outstanding test features
> I'm not too familiar with tun/tap, so the first outstanding test
> feature would be: it would make it easier for myself to test the
> unix port.
> >IMHO, pcap interface is more or less a subset of tun/tap.
> Tun/tap might be a method well evolved in the unix world, but asking 
> the other way round: does tun/tap provide anything useful that pcap 
> doesn't? If not, using pcap would make it easier to get started with 
> lwIP than tun/tap (IMHO).

At least a virtual Ethernet interface where I can bind a pppoe-server 
to check PPPoE :-)

> > Is there a valid use case where unix and win32 ports are used for
> > anything else than testing the stack ?
> 'Valid usecases' are always hard to define. What might be a valid
> use case for you might not be one for me. For widely used library
> like lwIP, I don't know if we could even find a consensus...
> Anyway, a very valid usecase for me is to test our *application*
> code on the PC. This does not mean testing the lwIP stack, but
> everything behind it using it. And if your embedded OS is posix-like
> (which our OSes are not, yet), it migh be a valid use case to
> develop on linux using the unix port.

Yes, I'm doing that, but that's still tests :-)

The only valid use case I see is to replace the Linux huge IP stack to a 
smaller one running in userland for very small devices running Linux 
because the Linux network maintainer refuse all patches to reduce the 
stack size. But it still looks wrong :(

> On the other hand, you're probably correct in that this doesn't have
> a high priority at all.

Indeed, it doesn't.


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]