[Top][All Lists]

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

Re: [lwip-users] sio.h Function Prototypes

From: Sylvain Rochet
Subject: Re: [lwip-users] sio.h Function Prototypes
Date: Wed, 11 May 2016 00:58:50 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

Hi Greg,

On Tue, May 10, 2016 at 10:14:32PM +0000, Greg Smith wrote:
> From: lwip-users [mailto:address@hidden On Behalf Of Sylvain Rochet
> > 
> Sorry -- I seem to have forgotten the " 't " while I was typing. :-) 
> ...sio_write() can'T be passed directly to pppos_create()...  It 
> definitely does not work and throws all sorts of compiler errors, as 
> you would expect (and hope).  Because of that, I already had to change 
> my functions around.  So getting rid of needing sio_write (as you 
> discussed below) isn't a big deal -- and is welcome.

Oh!, that's fun because with a simple cast it will actually work (as 
long as your don't need the sio ptr), that's not something I should 
recommend but given signatures involved here there is no reason that 
could not work :-)

> > Of course it is, PPP is not using the SIO API anymore for, humm, 
> > almost a year. There is not a single reference to SIO in the whole 
> > PPP code
> That said, sio.h is still included in ppp.c, ppp.h, and pppos.h.
> I guess I beg to differ here, per the above files including sio.h.  
> That's why I thought it might still be needed.  (Compiler errors when 
> I removed sio.h from my project.)
> Once I took those #includes out (and removed sio.h from my project), 
> everything compiled OK.  Hopefully it will run, too. :-)
> Is that something you can remove from the source files before official 
> release?  It would make things much more clear!

Good catch!, I just removed them.

> However, now that I've removed the extra call to sio_write(), I'd 
> still like to be able to pass arguments to the ppp_output_cb function.  
> In pppapi_pppos_create(), there is only one void *ctx_cb parameter.  I 
> assumed that was for arguments to the link status callback. But either 
> way, how can I pass separate parameters to each callback function?  (I 
> originally wanted to use this so I can compile lwIP as a library and 
> pass in another function pointer to an application-level call-back to 
> keep lwIP one more level decoupled from my main app.  I figured 
> another way to do it for my application, but it may be useful to 
> others down the road?)

Humm, the context is for all callbacks. That could be useful but saving 
RAM is the main lwIP goal, before code size, and before performance.

On most of the targets I use at work we are always reaching out of 
memory condition wayyyyy before out of flash condition so more code to 
reduce RAM usage (such as using bitfields in place of bool) is always 
welcomed :-)

> > (except in the documentation maybe to tell that we are not using it 
> > anymore :p).
> Speaking of documentation, the "how to convert from 1.4.x to 1.5.x" is 
> a pretty good guide.  But I wish the info on Wikia were updated.  
> There are some things still referring to 1.3.x, I think, and some 
> empty (or nearly empty) info pages.  Once 2.0 gets released, do you 
> know if there is going to be any effort to get that documentation 
> updated, too?

I don't know, but not by me. Given the number of advertising, trackers, 
and customer interaction scripts running in Wikia, I am not going to 
subscribe there.

Furthermore I like backups. No. I love backups. Documentation inside 
lwIP in text files properly versioned by Git means there is backups 
everywhere. If Wikia lose their data, all the documentation stored there 
is probably lost, that's not acceptable. Another thing why embedded 
documentation is great, when you download the release then it comes with 
the documentation that apply to the release you downloaded, while a wiki 
is for a version you usually don't even know.
(By the way, I changed 1.5.x to 2.0.x in the documentation, thank you 
for the hint ;-) ).


Attachment: signature.asc
Description: Digital signature

reply via email to

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