Erik Trulsson wrote:
On Fri, Oct 05, 2007 at 05:05:05PM -0700, Jack Vogel wrote:
On 10/5/07, Erik Trulsson <[EMAIL PROTECTED]> wrote:
On Fri, Oct 05, 2007 at 10:49:09PM +0000, Jack F Vogel wrote:
jfv 2007-10-05 22:49:09 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_6)
sys/conf files kern.pre.mk
sys/dev/em LICENSE if_em.c if_em.h
sys/modules/em Makefile
Added files: (Branch: RELENG_6)
sys/dev/em e1000_80003es2lan.c e1000_80003es2lan.h
e1000_82540.c e1000_82541.c e1000_82541.h
e1000_82542.c e1000_82543.c e1000_82543.h
e1000_82571.c e1000_82571.h e1000_82575.c
e1000_82575.h e1000_api.c e1000_api.h
e1000_defines.h e1000_hw.h
e1000_ich8lan.c e1000_ich8lan.h
e1000_mac.c e1000_mac.h e1000_manage.c
e1000_manage.h e1000_nvm.c e1000_nvm.h
e1000_osdep.h e1000_phy.c e1000_phy.h
e1000_regs.h
Removed files: (Branch: RELENG_6)
sys/dev/em if_em_hw.c if_em_hw.h if_em_osdep.h
Log:
MFC of Intel driver version 6.6.6
This adds our new modular shared code, support for MSI/MSIX, hardware
support for newer adapters, and a variety of bug fixes.
Am I right in thinking that this code is actually newer than the code
in -CURRENT (which seems to be version 6.5.3) ? If this is indeed the
case, then shouldn't this code have gone into -CURRENT first?
Yes, it is newer, the reason for this is the delta between what CURRENT
has and this is small, and I did not want to impact CURRENT while its
frozen getting ready for release.
That delta between CURRENT and this is also not just some hacking of
mine, its from my Intel release that has gone thru a whole test/validation
and bug fix period of months.
I would actually have liked to update BOTH CURRENT and STABLE with
this but I was holding off on CURRENT because there are no critical
bug fixes it doesnt have, and its about to be made into a release.
As I understand it the policy of FreeBSD is that new stuff *always* should
go into -CURRENT first before it is allowed to go into any -STABLE branch.
Please see
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.html
What do you expect to accomplish by lecturing a vendor who has shown
very good faith over the years in supporting FreeBSD? Maybe we should
tell Intel to piss off since you obviously know how to support their
hardware much better than they do.
Scott
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
