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.

21. Re: [PATCH] netdev_ops (score: 1)
Author: erg@xxxxxxxxx>
Date: Fri, 11 Jul 2003 21:04:23 +0100
Couldn't agree more. I blame acme -- he wants me to push it to be much wider in scope. Let's push _all_ the function pointers into netdev_ops. But this is a mere step 1. I don't have enough network-r
/archives/netdev/2003-07/msg00259.html (13,857 bytes)

22. Re: [PATCH] netdev_ops (score: 1)
Author: d S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 14 Jul 2003 02:53:54 -0300
Em Fri, Jul 11, 2003 at 09:04:23PM +0100, Matthew Wilcox escreveu: Hey, it was just a brainstorm session ;) Anyway, I'm heavily backlogged as I'm on a business trip for several days already, I'll try
/archives/netdev/2003-07/msg00283.html (10,746 bytes)

23. [PATCH] netdev_ops (score: 1)
Author: Matthew Wilcox <willy@xxxxxxxxxx>
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/msg00792.html (63,362 bytes)

24. Re: [PATCH] netdev_ops (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Tue, 08 Jul 2003 13:44:32 -0700
- add _len() ops for operations which previously had to kmalloc their own memory. - move the netdev_ops from ethtool.h to netdevice.h - makes some ops generic as requested by Jeff Garzik. I think net
/archives/netdev/2003-07/msg00799.html (10,825 bytes)

25. Re: [PATCH] netdev_ops (score: 1)
Author: Matthew Wilcox <willy@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/msg00800.html (9,365 bytes)

26. Re: [PATCH] netdev_ops (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
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/msg00805.html (9,328 bytes)

27. Re: [PATCH] netdev_ops (score: 1)
Author: Matthew Wilcox <willy@xxxxxxxxxx>
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/msg00822.html (65,945 bytes)

28. Re: [PATCH] netdev_ops (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 09 Jul 2003 10:11:04 -0700
- 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 count of elements, not a byte length.
/archives/netdev/2003-07/msg00823.html (11,929 bytes)

29. Re: [PATCH] netdev_ops (score: 1)
Author: Matthew Wilcox <willy@xxxxxxxxxx>
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/msg00826.html (11,470 bytes)

30. Re: [PATCH] netdev_ops (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 09 Jul 2003 11:24:35 -0700
Also, for the strings (labels) passed back to user space, is there any documentation for suggested values for these strings? Even though we can't be completely type-safe, if there were suggested val
/archives/netdev/2003-07/msg00828.html (12,035 bytes)

31. Re: [PATCH] netdev_ops (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Wed, 9 Jul 2003 14:14:59 -0400
The strings represent NIC-specific attributes. Jeff
/archives/netdev/2003-07/msg00831.html (10,449 bytes)

32. RE: [PATCH] netdev_ops (score: 1)
Author: "Feldman, Scott" <scott.feldman@xxxxxxxxx>
Date: Thu, 10 Jul 2003 00:47:13 -0700
Can we get a HAVE_NETDEV_OPS?
/archives/netdev/2003-07/msg00849.html (8,575 bytes)

33. Re: [PATCH] netdev_ops (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
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/msg00850.html (9,082 bytes)

34. RE: [PATCH] netdev_ops (score: 1)
Author: "Feldman, Scott" <scott.feldman@xxxxxxxxx>
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/msg00851.html (9,059 bytes)

35. Re: [PATCH] netdev_ops (score: 1)
Author: Matthew Wilcox <willy@xxxxxxxxxx>
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/msg00855.html (9,362 bytes)

36. Re: [PATCH] netdev_ops (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Thu, 10 Jul 2003 09:06:42 -0400
Can we get a HAVE_NETDEV_OPS? 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 dri
/archives/netdev/2003-07/msg00856.html (9,771 bytes)

37. Re: [PATCH] netdev_ops (score: 1)
Author: "David S. Miller" <davem@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/msg00873.html (8,916 bytes)

38. Re: [PATCH] netdev_ops (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
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/msg00899.html (9,800 bytes)

39. Re: [PATCH] netdev_ops (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 11 Jul 2003 15:32:15 -0400
Comments: 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. I
/archives/netdev/2003-07/msg00931.html (13,555 bytes)

40. Re: [PATCH] netdev_ops (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
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/msg00932.html (14,091 bytes)


This search system is powered by Namazu