| 0fa04772ab1e092fce34b658d6cc4e6f6b59be1d |
|
03-Jul-2010 |
Thomas Graf <tgraf@suug.ch> |
Fix compile warning in utils.c
/external/libnl/lib/utils.c
|
| 52d6b8b9ee21b4bc112cc8a5d6f440536dd7fde0 |
|
14-Jan-2010 |
Jose Ignacio Naranjo Hernández <joseignacio.naranjo@gmail.com> |
Fix a bug when calculating ticks_per_usec
I've noticed a wrong behavior when setting up some delays in a netem
qdisc. I will try to make the things easier for the reader describing
the calls path.
To set up a delay (or jitter...) I use 'rtnl_netem_set_delay' which
requires an int parameter that tells the delay in micro seconds. Inside
this func, the delay is set up with the help of 'nl_us2ticks', which is
just an arithmetic operation (us * ticks_per_usec), where us is the
input parameter and ticks_per_usec is a global variable initialized in
'get_psched_settings'. And here is the problem:
If this variable is going to be calculated using '/proc/net/psched', I
think the file scan is not done properly.
I don't understand what the meaning of the asterisk is here:
int r = fscanf(fd, "%08x%08x%08x%*08x", &tick, &us, &nom);
if (4 == r && nom == 1000000 && !got_tick)
ticks_per_usec = (double)tick/(double)us;
The execution path never gets in the if statement, because r is always
3, and if the fourth parameter is read (avoiding the asterisk), there is
no variable to store it in, so it comes a segv. In my opinion we can get
rid of the if statement, because I think the proc psched file has always
a fixed format of 4 parameters, and 'nom' is always 1000000
(http://lxr.linux.no/#linux+v2.6.32/net/sched/sch_api.c#L1678).
Find attached a patch I did, if I am correct.
/external/libnl/lib/utils.c
|
| 6782b6f709d03877a5661a4c8d8f8bd1b461f43f |
|
10-Dec-2008 |
Thomas Graf <tgr@plip.localdomain> |
restructure module documentation order
split hiearchy into one top level module per library
/external/libnl/lib/utils.c
|
| c48a17694b6719606fa76fdad8a5cef3289cb42c |
|
16-Jun-2008 |
Thomas Graf <tgr@lsx.localdomain> |
Extend nl_time2int() and rename it to nl_str2msec()
Support parsing of more complex time duration input.
/external/libnl/lib/utils.c
|
| d84430702496f617c01c5e2d27d0e82e02390bb7 |
|
23-May-2008 |
Thomas Graf <tgr@lsx.localdomain> |
Remove old line counting while dumping
/external/libnl/lib/utils.c
|
| 00466b0f95af19623c6536edafca6904945ced83 |
|
20-May-2008 |
Thomas Graf <tgr@lsx.localdomain> |
Return libnl error codes in translation routines
/external/libnl/lib/utils.c
|
| 8cd39c9f4ca8731279ea6467a9d489902fcae7f9 |
|
15-May-2008 |
Thomas Graf <tgr@lsx.localdomain> |
Uninline various functions to save 7K code
/external/libnl/lib/utils.c
|
| 8a3efffa5b3fde252675239914118664d36a2c24 |
|
14-May-2008 |
Thomas Graf <tgr@lsx.localdomain> |
Thread-safe error handling
In order for the interface to become more thread safe, the error
handling was revised to no longer depend on a static errno and
error string buffer.
This patch converts all error paths to return a libnl specific
error code which can be translated to a error message using
nl_geterror(int error). The functions nl_error() and
nl_get_errno() are therefore obsolete.
This change required various sets of function prototypes to be
changed in order to return an error code, the most prominent
are:
struct nl_cache *foo_alloc_cache(...);
changed to:
int foo_alloc_cache(..., struct nl_cache **);
struct nl_msg *foo_build_request(...);
changed to:
int foo_build_request(..., struct nl_msg **);
struct foo *foo_parse(...);
changed to:
int foo_parse(..., struct foo **);
This pretty much only leaves trivial allocation functions to
still return a pointer object which can still return NULL to
signal out of memory.
This change is a serious API and ABI breaker, sorry!
/external/libnl/lib/utils.c
|
| 662887c052f0fcd98287e2a7fa5843a4f66ca256 |
|
29-Apr-2008 |
Thomas Graf <tgr@lsx.localdomain> |
Export nl_dump_line() and automatically count lines while dumping
/external/libnl/lib/utils.c
|
| 3c56ed5787481a06703ffb25561df3dd56b447bd |
|
18-Dec-2007 |
Thomas Graf <tgr@deb.localdomain> |
Read debugging environment variable when initializing the library
/external/libnl/lib/utils.c
|
| 508685c269275cb7ba3471c75abc689b4e3839b1 |
|
15-Sep-2007 |
Thomas Graf <tgraf@suug.ch> |
Export interface to define objects
This interface was internal so far which required all code defining
objects to be compiled with the sources available.
This change exposes struct nl_object_ops which seems safe as it
is not supposed to be embedded in other structures.
Patch contains extensive documentation to help with the creation
of own object implementations.
/external/libnl/lib/utils.c
|
| 44d362409d5469aed47d19e7908d19bd194493a4 |
|
15-Sep-2007 |
Thomas Graf <tgraf@suug.ch> |
Initial import
/external/libnl/lib/utils.c
|