lwIP - A Lightweight TCP/IP stack - Patches: patch #5785, Integrate SNMP initialization in...
You are not allowed to post comments on this tracker with your current authentication level.
patch #5785: Integrate SNMP initialization in tcpip.c
Submitter: | Frédéric Bernon <fbernon> | ||
Submitted: | Tue 06 Mar 2007 07:50:13 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Wont Do | Privacy: | Public |
Assigned to: | fbernon | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Wed 23 May 2007 08:40:02 AM UTC, comment #17: |
Frédéric Bernon <fbernon> |
Mon 12 Mar 2007 12:01:03 PM UTC, comment #16: I don't like 64-bit in lwIP core, for the following reasons:
|
Dmitry Potapov <dpotapov> |
Mon 12 Mar 2007 10:10:29 AM UTC, comment #15: I don't have enough understanding of the many timeout related issues that are going on at the moment to make a good decision I'm afraid. However, I don't want this to hold things up and I'm happy for you (collectively) to make a decision if some consensus can be reached. I would prefer:
|
Kieran Mansley <kieranm> |
Mon 12 Mar 2007 09:29:55 AM UTC, comment #14: Hm, 64 bit is what I would favour, also. But 64-bit calculating in on a 16-bit processor is not what you can call fast, I think! Plus we need that timestamp rather often...
|
Simon Goldschmidt <goldsimon> |
Mon 12 Mar 2007 09:10:39 AM UTC, comment #13: Just an alternative idea: most of "timestamp" features are implemented as "unsigned int 64bits". With that, you can use it like "absolute" time (like file times, "number of 100-nanosecond intervals since January 1, 1601"), or relative time from boot time.
|
Frédéric Bernon <fbernon> |
Sun 11 Mar 2007 10:37:20 PM UTC, comment #12: I think there are two alternatives:
|
Dmitry Potapov <dpotapov> |
Sun 11 Mar 2007 07:54:25 PM UTC, comment #11:
|
Frédéric Bernon <fbernon> |
Sun 11 Mar 2007 07:36:16 PM UTC, comment #10: Just wanted to have a "testing" branch, so that we only merge changes into HEAD if we are sure they work... I know DEVEL_SOCKET is a bad name...
|
Simon Goldschmidt <goldsimon> |
Sun 11 Mar 2007 06:26:37 PM UTC, comment #9: I think your idea to use another CVS branch for features like timestamps is good, but multithread stability and netconn api are more features to add to HEAD. Except, of course, if you use timestamps for that (is it?). But this is my point of view....
|
Frédéric Bernon <fbernon> |
Sun 11 Mar 2007 06:03:38 PM UTC, comment #8: That's a good idea, but I would like to postpone that from CVS HEAD. I've made a new branch DEVEL_SOCKET, where I'm working on socket stability (multithreading stability, so netconn_ API also).
|
Simon Goldschmidt <goldsimon> |
Sun 11 Mar 2007 05:51:12 PM UTC, comment #7: To reduce timer overhead for snmp_get_sysuptime, I propose to write something like that :
*/
|
Frédéric Bernon <fbernon> |
Wed 07 Mar 2007 09:40:04 AM UTC, comment #6: Ok, right, documentation is important.
|
Frédéric Bernon <fbernon> |
Wed 07 Mar 2007 09:33:52 AM UTC, comment #5: I think this is a problem that would be best solved with documentation rather than adding an extra function. That way the developers will be able to make the right decision about which modules to initialise, and the documentation could include your suggested function as a sensible default. |
Kieran Mansley <kieranm> |
Wed 07 Mar 2007 09:06:57 AM UTC, comment #4: Agree with you Kieran about functions called by lwip_init. In the current options availables, we can't know is we are using the tcpip.c thread. I think that adding a new option (yes, I know, another one), it will be possible to remove any extra code or initialization which are not used per rawapi users...
|
Frédéric Bernon <fbernon> |
Wed 07 Mar 2007 09:00:04 AM UTC, comment #3: I think adding the lwip_init function might cause more problems than it solves, as many people wont want or need to initialise all the modules - particularly if using the raw API. |
Kieran Mansley <kieranm> |
Wed 07 Mar 2007 08:58:26 AM UTC, comment #2: Ye,s agree with you, timeout timer are not a perfect feature, and, in this case, I will prefer to be able to remove "snmp_inc_sysuptime()" and the variable "sysuptime" and to be able to define my "own" function "snmp_get_sysuptime" (based on platform timer). So, overhead will be reduce.
|
Frédéric Bernon <fbernon> |
Wed 07 Mar 2007 08:19:34 AM UTC, comment #1: Hm, I don't like the way SNMP gets it's sys_uptime anyway (since it produces high system load calling snmp_inc_sysuptime even if you have no client which reads it). AND it's not very accurate if called by an lwIP timeout timer (as stated in discussion to bug #19167).
|
Simon Goldschmidt <goldsimon> |
Tue 06 Mar 2007 07:50:13 PM UTC, original submission:
With the very useful Christiaan Simons's SNMP Agent, we can add this protocol to our products.
|
Frédéric Bernon <fbernon> |
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.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-05-23 | fbernon | Open/Closed | Open | Closed | |
2007-05-23 | fbernon | Status | In Progress | Wont Do |
Powered by Savane 3.13-02a9.
Corresponding source code
Ok, I close it because :
- features like "ticks" & "jiffies" to replace snmp timers will be another task
- we don't get a consensus about a lwip_init function (see first comments)