Linux-Kernel Archive: Re: RFC: per-socket statistics on receive Re: RFC: per-socket statistics on received/dropped packets From: Mark Mielke (mark@mark.mielke.cc) Date: Wed Jun 12 2002 - 09:53:55 EST Next message: Benjamin Herrenschmidt: "Re: PCI DMA to small buffers on cache-incoherent arch" Previous message: Hugh Dickins: "Re: 2.4.18 no timestamp update on modified mmapped files" In reply to: jamal: "Re: RFC: per-socket statistics on received/dropped packets" Next in thread: jamal: "Re: RFC: per-socket statistics on received/dropped packets" Reply: jamal: "Re: RFC: per-socket statistics on received/dropped packets" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Wed, Jun 12, 2002 at 09:00:08AM -0400, jamal wrote: > On Wed, 12 Jun 2002, Lincoln Dale wrote: > > At 08:33 AM 12/06/2002 -0400, jamal wrote: > > >If 3 people need it, then i would like to ask we add lawn mower > > >support that my relatives have been asking for the last 5 years. > > lawn-mower support sounds like a userspace application to me. > But we need a new system call support This is another non-argument not dissimilar to the method of arguing that David has used up to this point. If lawn-mower support (whatever that is) is something that people would use, then perhaps it *should* be added, even if it needs a new system call. You have not shown a valid argument against your own sarcastic suggestion, other than an implicit sneer. There is no evidence that only three people would use a feature that allows one to measure the exact bandwidth being used by a specific TCP/IP connection (including retransmissions). There is evidence that if such a patch was not accepted into the kernel that people that desired this feature would either reinvent the wheel, because they could not locate the private patch, likely doing it *wrong* because they did not have wonderful people such as David to make strategic suggestions regarding the exact implementation, or that they would find other less adequate ways of doing something that approximates what they actually need using existing functionality. Anyways... I'll drop out of this one as my presence here was only to try to encourage creativity, not to create any anger. I never intended to slight David. I would like to see stronger arguments presented when saying no to a feature, as they allow me, and others around here, to learn. Cliche's don't teach me anything, and they make the speaker appear less qualified. (Appearance may != Reality) Good work David, and I look forward to seeing clearer objections. mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
-
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/
Next message: Benjamin Herrenschmidt: "Re: PCI DMA to small buffers on cache-incoherent arch" Previous message: Hugh Dickins: "Re: 2.4.18 no timestamp update on modified mmapped files" In reply to: jamal: "Re: RFC: per-socket statistics on received/dropped packets" Next in thread: jamal: "Re: RFC: per-socket statistics on received/dropped packets" Reply: jamal: "Re: RFC: per-socket statistics on received/dropped packets" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:25 EST
