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 current e1000.
Sounds like a reasonable approach to me (it has plenty of
precedent). But
I forget what all the other issues were, so ignore me.
Given past history with duplicate drivers and the problems that they
cause -- I know, I've caused some of those problems :( -- I strongly
recommend against when it can be avoided.
Leaving e1000 with current hardware, and a new e1001 for newer
hardware should be easier to manage for all involved, without the
headaches that duplicate drivers cause.
Jeff,
ok first you hate the old e1000 and now you don't want to get rid of it ;)
I appreciate the pain a temporary dual driver situation gives; it
comes down to a few things that I can think of right now, if you see
more please add to the list.
1) users who find a bug in the new one silently use the old one rather
than reporting the bug; and only scream when the old one eventually
goes away (see ALSA/OSS duplication)
2) users who enable both in KConfig may get a "random" one
3) distros really prefer only 1 driver per PCI ID for their
infrastructure tools
4) there will be resistance against deleting the old one meaning it
might not happen
While the pain won't be zero, I know there are some simple things that
can be done to make it significantly less:
1) Make sure that the various feature-removal files and KConfig
clearly mark the old one as "going away" early on, make the old one
printk that it's the older driver and stick a hard date on it. This
should at least ease [1] and [4] above
2) After a minimal amount of shake-out time (say one kernel release),
make the old e1000 not export the PCI IDs in it's module, but make it
a manual modprobe. This means people can still use the old one, but
distro tools will pick the new one automatically
[and if there is any doubt about a specific PCI ID model temporarily,
that one can be done the other way around]
3) Have a config option which does what you say; allow both drivers to
be there but with non-overlapping PCI IDs; where exactly the new/old
split is is up for discussion, and it can even move over time
4) Work with the distro maintainers to default their development
snapshots as quickly as possible to the new driver so that it gets as
much testing as possible quickly; yet at the same time for their
security fixes and released updates they can use the 3) option
5) once there is some confidence in the new driver, put a patch into
-mm that makes the old driver really hard to select in KConfig; this
in preparation for removal later on (hey this worked for devfs ;)
6) put more or less a code freeze on the old driver; it should remain
compiling but it's ok to be bug-to-bug compatible with what is there
at the moment the new driver goes into the tree.
Personally I'm convinced this is a managable process with a reasonable
assurance that the old driver really can go away after 2 kernel
releases (as long as Auke and co are on top of bugreports about
regressions, I don't see why not). What is needed of course is some
level of strictness/determination to get rid of the old one after the
reasonable time period.
if you have other concerns about temporarily having two drivers that
are real showstoppers , please put them on the table; it might well be
possible to find a reasonable way to solve/mitigate them.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
