Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+ethtool_ops\s+rev\s+4\s*$/: 54 ]

Total 54 documents matching your query.

1. [PATCH] ethtool_ops rev 4 (score: 1)
Author: Matthew Wilcox <willy@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 16:02:32 +0100
At 55k, I doubt you want to see it posted to the list; patch is available from http://ftp.linux.org.uk/pub/linux/willy/patches/ethtool4.diff and here's the diffstat drivers/net/8139too.c | 330 ++++++
/archives/netdev/2003-08/msg00003.html (9,231 bytes)

2. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 1 Aug 2003 11:40:21 -0400
Comments: * need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar * I still do not see the need to change a simple storage of a constant (into ethtool_gdrvinfo) into _four_ separate fu
/archives/netdev/2003-08/msg00004.html (9,344 bytes)

3. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 1 Aug 2003 12:25:36 -0400
It's standard netdevice.h practice, and, he didn't disagree w/ my rebuttal. It is needed. Additing a function hook each time you want to retrieve a new integer value? That's feels overly excessive to
/archives/netdev/2003-08/msg00006.html (10,244 bytes)

4. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Matthew Wilcox <willy@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 16:46:56 +0100
DaveM disagreed with that... slow path, sure, but increased stack usage. it's a tradeoff, and this way feels more clean to me. That means that any code which includes ethtool.h has to include types.h
/archives/netdev/2003-08/msg00011.html (9,900 bytes)

5. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 13:20:37 -0700
Absolutely not, it makes no sense whatsoever to have this. Jeff, stop and think. The whole _POINT_ of these ops are to avoid duplicated code. If someone is absolutely adament about supporting kernels
/archives/netdev/2003-08/msg00013.html (10,117 bytes)

6. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 18:35:31 -0400
Jeff Garzik wrote: It's an explicit goal to avoid changing the driver API in such a way that there is a remotely sane path to supporting older kernels. I, of course, meant the exact opposite here :)
/archives/netdev/2003-08/msg00014.html (10,097 bytes)

7. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 15:32:55 -0700
And then we'll have all of these functions present in the driver, unused, and we'll get tons of warning from gcc. The duplication of code is still there, and this is the main point. It's not interest
/archives/netdev/2003-08/msg00015.html (11,860 bytes)

8. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 15:34:39 -0700
I don't believe it's possible with netdev_ops, without undoing the entire purpose of what netdev_ops is trying to accomplish (elimination of code duplication). Show me, in code not words, how you are
/archives/netdev/2003-08/msg00016.html (10,082 bytes)

9. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 19:01:21 -0400
David S. Miller wrote: On Fri, 01 Aug 2003 18:26:37 -0400 Jeff Garzik <jgarzik@xxxxxxxxx> wrote: Strangely enough, creating a SET_ETHTOOL_OPS() macro (or netif_ethtool_ops or pick your name) reduces
/archives/netdev/2003-08/msg00018.html (13,789 bytes)

10. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 16:01:36 -0700
I don't understand. Where does this DO_ETHTOOL_OPS macro come from? Is it defined by kcompat? If so, how will drivers in vanilla 2.4.x trees end up with the DO_ETHTOOL_OPS define?
/archives/netdev/2003-08/msg00019.html (10,509 bytes)

11. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 16:08:57 -0700
Where does kcompat_set_ethtool_ops store the pointer if it does not exist in struct netdevice?
/archives/netdev/2003-08/msg00020.html (10,357 bytes)

12. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 19:17:57 -0400
David S. Miller wrote: On Fri, 01 Aug 2003 19:01:21 -0400 Jeff Garzik <jgarzik@xxxxxxxxx> wrote: A DO_ETHTOOL_OPS macro in the driver's ->do_ioctl -- intentionally not included in the kernel -- does
/archives/netdev/2003-08/msg00021.html (12,701 bytes)

13. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 16:19:37 -0700
You don't need DO_ETHTOOL_OPS and thus the merge-to-mainline pain at all if you do something like: 1) SET_ETHDEV_OPS() also overrides the ->do_ioctl() setting to a kcompat_netdev_ioctl() one, but rem
/archives/netdev/2003-08/msg00022.html (10,977 bytes)

14. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 19:35:20 -0400
Where does kcompat_set_ethtool_ops store the pointer if it does not exist in struct netdevice? Inside an area allocated by the kcompat lib. SET_ETHTOOL_OPS takes 'struct net_device *' and 'struct et
/archives/netdev/2003-08/msg00023.html (12,450 bytes)

15. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 16:34:15 -0700
Ok ok ok, we're converging :-) Please just comment on my other email suggesting a way to do away with DO_ETHTOOL_OPS. I'm OK with a SET_ETHTOOL_OPS() macro.
/archives/netdev/2003-08/msg00024.html (10,933 bytes)

16. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 1 Aug 2003 16:43:28 -0700
Like I said, I've got no problem with that part.
/archives/netdev/2003-08/msg00025.html (10,658 bytes)

17. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 19:09:35 -0400
David S. Miller wrote: On Fri, 01 Aug 2003 18:35:31 -0400 Jeff Garzik <jgarzik@xxxxxxxxx> wrote: We want to provide a sane, ifdef-free path to kcompat, where feasible. I don't believe it's possible w
/archives/netdev/2003-08/msg00027.html (12,206 bytes)

18. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 18:26:37 -0400
David S. Miller wrote: The whole _POINT_ of these ops are to avoid duplicated code. If someone is absolutely adament about supporting kernels without ops support they should not support it at all. Th
/archives/netdev/2003-08/msg00028.html (13,493 bytes)

19. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 01 Aug 2003 19:42:44 -0400
David S. Miller wrote: On Fri, 01 Aug 2003 19:17:57 -0400 Jeff Garzik <jgarzik@xxxxxxxxx> wrote: Solution #2 chooses to create a tiny bit more merge-to-mainline pain, but also keeps the mainline kern
/archives/netdev/2003-08/msg00030.html (12,047 bytes)

20. Re: [PATCH] ethtool_ops rev 4 (score: 1)
Author: Matthew Wilcox <willy@xxxxxxxxxx>
Date: Sat, 2 Aug 2003 23:21:45 +0100
OK, now that the two of you thrashed out a design, here's my implementation: diff -u drivers/net/8139too.c drivers/net/8139too.c -- drivers/net/8139too.c 31 Jul 2003 17:09:52 -0000 +++ drivers/net/81
/archives/netdev/2003-08/msg00044.html (13,619 bytes)


This search system is powered by Namazu