Search String: Display: Description: Sort:

Results:

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

Total 44 documents matching your query.

1. [PATCH] netdev_ops (score: 1)
Author: xxx>
Date: Tue, 8 Jul 2003 17:30:42 +0100
After a conversation with acme, I realised that ethtool_ops is far too narrow scope. What we need are netdev_ops. This patch renames the ethtool_ops to netdev_ops and fixes some other minor flaws: -
/archives/netdev/2003-07/msg00103.html (63,362 bytes)

2. Re: [PATCH] netdev_ops (score: 1)
Author: @xxxxxxxxxx>
Date: Tue, 08 Jul 2003 13:44:32 -0700
Matthew Wilcox wrote: After a conversation with acme, I realised that ethtool_ops is far too narrow scope. What we need are netdev_ops. This patch renames the ethtool_ops to netdev_ops and fixes some
/archives/netdev/2003-07/msg00110.html (10,589 bytes)

3. Re: [PATCH] netdev_ops (score: 1)
Author: Krishna Kumar <krkumar@xxxxxxxxxx>
Date: Tue, 8 Jul 2003 22:25:51 +0100
Well, they don't actually need it -- these are more attributes of the underlying driver than they are of any individual network device. I suspect at least one of them isn't needed, and I'm sure the e
/archives/netdev/2003-07/msg00111.html (9,287 bytes)

4. Re: [PATCH] netdev_ops (score: 1)
Author: Hemminger <shemminger@xxxxxxxx>
Date: Tue, 08 Jul 2003 15:08:35 -0700 (PDT)
Well, they don't actually need it -- these are more attributes of the underlying driver than they are of any individual network device. Not true, at least for the regs len different variants of the
/archives/netdev/2003-07/msg00116.html (9,216 bytes)

5. Re: [PATCH] netdev_ops (score: 1)
Author: en <ak@xxxxxxx>
Date: Wed, 9 Jul 2003 17:15:20 +0100
Changes since yesterday's patch: - Make all methods take the struct net_device as suggested by Ben Greear. - Rename self_test_len() and get_stats_len() to *_count() to reflect that they return a coun
/archives/netdev/2003-07/msg00133.html (65,786 bytes)

6. Re: [PATCH] netdev_ops (score: 1)
Author: ik@xxxxxxxxx>
Date: Wed, 09 Jul 2003 10:11:04 -0700
Matthew Wilcox wrote: Changes since yesterday's patch: - Make all methods take the struct net_device as suggested by Ben Greear. - Rename self_test_len() and get_stats_len() to *_count() to reflect t
/archives/netdev/2003-07/msg00134.html (11,902 bytes)

7. Re: [PATCH] netdev_ops (score: 1)
Author: n Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 9 Jul 2003 18:25:25 +0100
This patch makes only user-invisible changes. I'm trying to establish a base for further cleanups (eg, acme wants to look at unifying the wireless ops and the existing net_device function pointers in
/archives/netdev/2003-07/msg00137.html (11,272 bytes)

8. Re: [PATCH] netdev_ops (score: 1)
Author: atthew Wilcox <willy@xxxxxxxxxx>
Date: Wed, 09 Jul 2003 11:24:35 -0700
Jeff Garzik wrote: On Wed, Jul 09, 2003 at 10:11:04AM -0700, Ben Greear wrote: Also, for the strings (labels) passed back to user space, is there any documentation for suggested values for these stri
/archives/netdev/2003-07/msg00139.html (11,873 bytes)

9. Re: [PATCH] netdev_ops (score: 1)
Author: <yoshfuji@xxxxxxxxxxxxxx>
Date: Wed, 9 Jul 2003 14:14:59 -0400
The strings represent NIC-specific attributes. Jeff
/archives/netdev/2003-07/msg00142.html (10,251 bytes)

10. RE: [PATCH] netdev_ops (score: 1)
Author: xxxxxxxxxxxx>
Date: Thu, 10 Jul 2003 00:47:13 -0700
Can we get a HAVE_NETDEV_OPS?
/archives/netdev/2003-07/msg00160.html (8,575 bytes)

11. Re: [PATCH] netdev_ops (score: 1)
Author: xxxxxx>
Date: Thu, 10 Jul 2003 00:42:07 -0700 (PDT)
Can we get a HAVE_NETDEV_OPS? Don't tell me you're seriously considering having _TWO_ copies of all this code sitting around? At that point backwards compat becomes absolutely rediculious. If it's im
/archives/netdev/2003-07/msg00161.html (8,986 bytes)

12. RE: [PATCH] netdev_ops (score: 1)
Author: xxxxxx>
Date: Thu, 10 Jul 2003 01:18:50 -0700
Either way we end up with duplicated code. If I stick with the current scheme (no netdev_ops), I duplicate in the driver all of the wrapper code that Matt has pulled into netdev_ops. Each driver tha
/archives/netdev/2003-07/msg00162.html (9,059 bytes)

13. Re: [PATCH] netdev_ops (score: 1)
Author: xxx>
Date: Thu, 10 Jul 2003 12:21:49 +0100
I'll seriously consider it ... once we have a better idea where this is all going. I'm a big fan of having _shared_ compatibility code rather than something in each driver. Obviously we'll want to sh
/archives/netdev/2003-07/msg00166.html (9,266 bytes)

14. Re: [PATCH] netdev_ops (score: 1)
Author: xxxxxxxxx>
Date: Thu, 10 Jul 2003 09:06:42 -0400
Matthew Wilcox wrote: On Thu, Jul 10, 2003 at 12:47:13AM -0700, Feldman, Scott wrote: Can we get a HAVE_NETDEV_OPS? I'll seriously consider it ... once we have a better idea where this is all going.
/archives/netdev/2003-07/msg00167.html (9,757 bytes)

15. Re: [PATCH] netdev_ops (score: 1)
Author: on <jkenisto@xxxxxxxxxx>
Date: Thu, 10 Jul 2003 13:37:37 -0700 (PDT)
From: "Feldman, Scott" <scott.feldman@xxxxxxxxx> Date: Thu, 10 Jul 2003 01:18:50 -0700 With HAVE_NETDEV_OPS, you're right, we're maintaining the wrapper code outside the kernel. But, it does leave th
/archives/netdev/2003-07/msg00184.html (8,820 bytes)

16. Re: [PATCH] netdev_ops (score: 1)
Author: shfuji@xxxxxxxxxxxxxx>
Date: Thu, 10 Jul 2003 20:53:00 -0400
David S. Miller wrote: From: "Feldman, Scott" <scott.feldman@xxxxxxxxx> Date: Thu, 10 Jul 2003 01:18:50 -0700 With HAVE_NETDEV_OPS, you're right, we're maintaining the wrapper code outside the kernel
/archives/netdev/2003-07/msg00210.html (9,599 bytes)

17. Re: [PATCH] netdev_ops (score: 1)
Author: reearb@xxxxxxxxxxxxxxx>
Date: Fri, 11 Jul 2003 15:32:15 -0400
1) The _ops are either too limited in scope, or too wide in scope. We have a bunch of function pointers in struct net_device. We are adding a bunch more func ptrs in a new struct foo_ops. If it is c
/archives/netdev/2003-07/msg00242.html (13,376 bytes)

18. Re: [PATCH] netdev_ops (score: 1)
Author: zik <jgarzik@xxxxxxxxx>
Date: Fri, 11 Jul 2003 12:51:24 -0700
1) The _ops are either too limited in scope, or too wide in scope. We have a bunch of function pointers in struct net_device. We are adding a bunch more func ptrs in a new struct foo_ops. If it is ca
/archives/netdev/2003-07/msg00243.html (14,291 bytes)

19. Re: [PATCH] netdev_ops (score: 1)
Author: reearb@xxxxxxxxxxxxxxx>
Date: Fri, 11 Jul 2003 15:58:56 -0400
It's trivial to return the existing values in the gdrvinfo struct in addition to a new ethtool_count struct. Full ABI compat is maintained. ethtool.h isn't included in the "lots of stuff" that is cha
/archives/netdev/2003-07/msg00244.html (12,195 bytes)

20. Re: [PATCH] netdev_ops (score: 1)
Author: f Halasa <khc@xxxxxxxxx>
Date: Fri, 11 Jul 2003 13:07:07 -0700
Jeff Garzik wrote: Regardless, addressing your point, I consider ethtool.h a kernel-internal header, that's why it uses internal kernel types. Anybody who copies it to userspace must deal with that.
/archives/netdev/2003-07/msg00245.html (11,655 bytes)


This search system is powered by Namazu