Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Jan 2005 13:14:30 +0000
From:      Matt Dawson <matt@mattsnetwork.co.uk>
To:        "Simon L. Nielsen" <simon@freebsd.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: MFCs?
Message-ID:  <200501011314.30584.matt@mattsnetwork.co.uk>
In-Reply-To: <20050101125734.GF761@zaphod.nitro.dk>
References:  <200501011217.13171.matt@mattsnetwork.co.uk> <20050101125734.GF761@zaphod.nitro.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 01 Jan 2005 12:57, Simon L. Nielsen wrote:
> Sam has already said that the wlan parts will not be MFC'ed since they
> break the API/ABI.

Hmm, that's what I thought. It seemed to touch too many other bits of the=20
networking code to be that simple. I will stick with 5.x for now. The ath=20
board is in the server providing hostap service. It would have been nice to=
=20
have proper 54Mbps support instead of the current 11Mbps, but I can't risk=
=20
all the other services this box runs breaking. Ah well...
>
> I would suspect (read I don't know for sure and it's S=F8ren's call)
> that the ata changes are going to MFC'ed, but since there are some
> quirks in the ata code in CURRENT at the moment, which are being
> worked on, I wouldn't hold my breath for the MFC.

I won't. I don't use the ITE RAID on the Gigabyte board anyway, and the=20
support for the VIA SATA is rock-solid. The reason I wanted to know was tha=
t=20
I found this board to be solid and stable and it would be nice to be able t=
o=20
recommend an AMD64 board with 100% support. Even the ACPI is flawless on th=
is=20
board. Its one let-down is the ITE device which doesn't even work as a norm=
al=20
ATA controller.

Yes, OK, I should be running -CURRENT with an AMD64 anyway, I know ;-)

Thanks for the information.
=2D-=20
Matt Dawson.

matt@mattsnetwork.co.uk
MD2657-RIPE OpenNIC M_D9



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501011314.30584.matt>