Arjan van de Ven wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named
differently, pick any name) that contains the new code base,
side-by-side into
Roland Dreier wrote:
one possibility would be to merge e1000new with support only for chips
not supported by e1000, and semi-freeze e1000 (fixes only, new device
support goes into e1000new).
indeed.
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
James Chapman wrote:
I envisage something like this:-
e1000_core.c- common code used by all drivers of the e1000 family.
Exports functions used by actual drivers. Loadable
as a separate module when built as a module.
e1000_82541.c- driver for 82541
e1000_82542.c-
I reject the notion that a flag day switchover for a huge mass of
e1000 users is the correct path. I do not think that best serves Linux
users.
so the options we have is do it one pci id a time; and the suggestion
by others like Christoph has been to make the split at the PCI Express
Kok, Auke wrote:
Jeff Garzik wrote:
* The multitude of tiny, fine-grained operations for MAC, NVM, PHY,
etc. is a signal that organization is backwards. You should be
creating hardware-specific high level operations (PHY layer hooks,
net_device hooks, interrupt handler) that call out to
On 7/6/07, Jeff Garzik [EMAIL PROTECTED] wrote:
OK, just looked through the driver. I think its structured inside-out
from what it should be.
* The multitude of tiny, fine-grained operations for MAC, NVM, PHY, etc.
is a signal that organization is backwards. You should be creating
Jeff Garzik wrote:
OK, just looked through the driver. I think its structured inside-out
from what it should be.
Comments:
* is a clear improvement from current e1000
* The multitude of tiny, fine-grained operations for MAC, NVM, PHY, etc.
is a signal that organization is backwards. You
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named differently, pick
any name) that contains the new code base, side-by-side into the kernel with the
current e1000.
Sounds
Kok, Auke wrote:
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named
differently, pick any name) that contains the new code base,
side-by-side into the kernel with the
one possibility would be to merge e1000new with support only for chips
not supported by e1000, and semi-freeze e1000 (fixes only, new device
support goes into e1000new). Then if there are some devices that are
more naturally supported by e1000new, we could later on merge patches
to move support
10 matches
Mail list logo
