Linus Torvalds wrote:You mean never ever remove PCI-E support from e1000? Won't that will inflict long term headaches on the people that matter most -- users and maintainers -- to avoid short term headaches for kernel power users? To review the overall situation, * e1000 supports so many chips, that making a change for new hardware in e1000 involves breaking stability of older chips * //You know this// from past kernel history, when late-breaking e1000 changes for new hardware wound up breaking working setups on multiple occasions * There is 100% agreement that e1000 is a maintenance nightmare, from the people who actually touch the code (or even read it). * Therefore, e1000e receives new h/w support and new devel, leaving e1000 to sit and be stable However, due to a mistake now released to the public -- a tiny few PCI-E chips are supported by e1000 -- you have a widely disparate feature set: e1000, old chips: full support e1000, a few PCI-E chips: basic support e1000e, all PCI-E chips: full support Since e1000e is all new and fancy AND CLEAN, the code for the same chips is different -- thus Intel must make every PCI-E fix _twice_. It also means WE HAVE TO KEEP TOUCHING E1000, while supporting PCI-E chips. After this PCI-E issue is resolved, I want to let e1000 sit and be stable and not be touched. For a temporary situation, this is fine. Give me transition suggestions, please! For a permanent situation, that sucks. Distros will ship e1000 sans PCI-E support, which means you are asking that PCI-E support be maintained indefinitely, purely for the few kernel hackers that still use it? I __don't care__ how we get there, but a permanent situation where e1000 continues to support a few PCI-E chips in basic mode seems the least desireable of all available options. Wait six months? Sure. Whatever. As long as we get to where we can disable PCI-E support in e1000. Jeff --
| Andy Whitcroft | Re: 2.6.22 -mm merge plans -- pfn_valid_within |
| Linus Torvalds | Linux 2.6.27-rc8 |
| Fernando Luis | [PATCH] affinity is not defined in non-smp kernels - x86_64 |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Wink Saville | Using git with Eclipse |
| Andy Parkins | svn:externals using git submodules |
| Jan Wielemaker | [PATCH] git-shell and git-cvsserver |
| Alf Mikula | Migrating a git repository to subversion |
| Leon Dippenaar | New tcp stack attack |
| Richard Stallman | Real men don't attack straw men |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| (private) HKS | Re: sshd_config(5) PermitRootLogin yes |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Pavel Emelyanov | [PATCH net-2.6.25 9/11][INET] Merge sys.net.ipv4.ip_forward and sys.net.ipv4.conf.... |
| Evgeniy Polyakov | Re: [Bugme-new] [Bug 10556] New: IPVS sync_backup oops |
| Johannes Berg | Re: wireless vs. alignment requirements |
