-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 04 July 2003 05:47, Jan-Benedict Glaw wrote:
<snip>
> Well... I don't really like to break userspace, but why don't we simply
> make packet/traffic counters long long / u_int64_t? This way, we'd
> simply keep almost all drivers untouched and only need to fiddle with
> some sprints()/printk() statements?
I'm no hardware expert, however, that approach contains potential race
condition - not a system critical one, but something we should be concerned
about. If one cpu tries to read a u_int64_t variable while another tries to
update it, the worst case scenario is that the reader will get the high
32-bits before the write, and low 32-bit after the write, now if the counter
overflow, the number would be off by 4GB! (This only applies to 32-bit
architectures.) True, there are cache coherency algorithms, etc...
> Really, how many programs use the current statistics? I'd prefer to
> modify them over adding strange patches like this one to the kernel...
I believe that on any kind of router some at some point in time would like to
know the data transfered.
Jeff.
- --
Keyboard not found!
Press F1 to enter Setup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/BcADwFP0+seVj/4RAq2TAKDS0oAnj0/PrCuPoxdQF0euBiy6LACeMHqk
gWJhwub4y0VtQmC/hcevJB4=
=RCSe
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:23 EST