Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+netdev

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)

Current List: 21 - 40
Page: [1] [2] [3]