[Top][All Lists]

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

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

From: Greg Smith
Subject: Re: [lwip-users] sio.h Function Prototypes
Date: Tue, 10 May 2016 22:14:32 +0000

Hi, Sylvain.


From: lwip-users [mailto:lwip-users-bounces+address@hidden On Behalf Of Sylvain Rochet
Sent: Tuesday, 10 May 2016 17:14

Hi Greg,



On Tue, May 10, 2016 at 03:24:36PM +0000, Greg Smith wrote:

> From: Sylvain Rochet [mailto:address@hidden]

> > 

> > Not really, the last user of the SIO framework is SLIP. The SIO API

> > sucks, I proposed my help to get rid of it in SLIP in

> > <address@hidden<mailto:address@hidden

> > dator.net>> but the change was not acknowledged.


> There are so many other changes in the PPP, that I, personally, have

> had to make enough changes that this would not bother me if it broke

> compatibility.


I guess you misread. PPP is not SLIP. PPP is not using the SIO API anymore, SLIP is the last SIO user.

Yes, that makes sense.  I think I had just read Simon's comment about compatibility and didn't pay attention that this is for SLIP only. 

That said, sio.h is still included in ppp.c, ppp.h, and pppos.h.


> (It almost does anyway because sio_write() can be passed directly to

> pppos_create(), for example.)


Well, considering:


PPP output callback signature is:

  u32_t ppp_output_cb(ppp_pcb *pcb, u8_t *data, u32_t len, void *ctx);


sio_write signature is:

  u32_t sio_write(sio_fd_t fd, u8_t *data, u32_t len);


If it works, that's only by luck, because you only need data and len,

and because the size of a sio_fd_t is the same size of a ppp_pcb*

because they are probably both pointers, that's not something that was

done on purpose.

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.


> This is basically where I was headed myself, but it seems redundant;

> therefore, I was figuring I was doing something wrote.  Ideally, if I

> could get rid of sio.h altogether, that would seem to be cleaner.  Do

> you think that is possible in the current state of 2.0.0RC1? Either

> way, for now, I'll do much like what you've listed here.


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

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!


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?)


(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?



> Thank you for all your help!


You're welcome :)





-- Greg

This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com

reply via email to

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