lwIP - A Lightweight TCP/IP stack - Tasks: task #6833, netif.h: add netif->poll() /...
You are not allowed to post comments on this tracker with your current authentication level.
task #6833: netif.h: add netif->poll() / create netif_poll_all() to simplify porting
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Sun 29 Apr 2007 05:54:56 PM UTC | ||
Category: | Network drivers | Should Start On: | Sun 29 Apr 2007 12:00:00 AM UTC |
Should be Finished on: | Sun 29 Apr 2007 12:00:00 AM UTC | Priority: | 1 - Later |
Status: | None | Privacy: | Public |
Assigned to: | None | Percent Complete: | 0% |
Open/Closed: | Closed | Planned Release: | None |
Effort: | 0.00 |
Mon 30 Apr 2007 01:43:57 PM UTC, comment #2: |
Simon Goldschmidt <goldsimon> |
Mon 30 Apr 2007 01:34:13 PM UTC, comment #1: Just my opinion, but I don't see any real value in this to warrant extra code/data. In the majority of cases, this would just convert a native driver's poll in a main outer loop to an API call that just does exactly the same thing, but now has to conform to an API and fit into the netif abstraction.
|
Jonathan Larmour <jifl> |
Sun 29 Apr 2007 05:54:56 PM UTC, original submission:
This idea comes from linux, actually: if drivers don't have an interrupt, they can specify a function poll() which handles the receiving of packets.
|
Simon Goldschmidt <goldsimon> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-04-30 | goldsimon | Open/Closed | Open | Closed |
Powered by Savane 3.13-02a9.
Corresponding source code
I had some more in the back of my mind when I wrote this and I agree, that (besides easier porting) we don't really need it, now.
I was thinking about the following scenario: we could protect all access to stack-internal functions and modify the socket/netconn API to be configured call directly into the stack (with locking instead of messages. That way you could easily use a sequential API without an OS. Only you have to make sure the netif can input packets when it wants and the timers are called. You can then call netif_poll_all() & sys_check_timers() to let the stack run a bit.
But as I said, that's an idea for the far future and I'm going to test it in private, first (if it gives enough performance) and not going to bother the rest of you with it until I have positive results ;-)
OK, closing this. (Maybe I'll reopen it some time...)