| Author |
Message |
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
 Posted: Sat Apr 01, 2006 5:33 pm Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, 15 Mar 2006, Robert Watson wrote:
| Quote: | In order to begin to merge revised socket/pcb code, required to fix a number
of current races manifesting in the TCP code under load, and required for
breaking out the tcbinfo lock which is a significant bottleneck in high
performance TCP and multi-processor TCP scalability, I will disconnect
netatm and dependent components from the build on April 1, 2006. At that
point, I will merge updated socket and pcb reference counting.
|
Per this e-mail (and the associated thread), socket/pcb reference counting
changes have been committed that likely render netatm further disfunctional.
Robert N M Watson
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
Brooks Davis
*nix forums addict
Joined: 14 Jun 2002
Posts: 97
|
| Posted: Wed Mar 29, 2006 6:07 pm Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, Mar 29, 2006 at 11:13:34AM +0000, Robert Watson wrote:
| Quote: |
On Wed, 29 Mar 2006, Harti Brandt wrote:
On Wed, 29 Mar 2006, Robert Watson wrote:
RW>On Wed, 15 Mar 2006, Robert Watson wrote:
RW
RW>> In order to begin to merge revised socket/pcb code, required to fix a
RW>> number of current races manifesting in the TCP code under load, and
RW>> required for breaking out the tcbinfo lock which is a significant
RW>> bottleneck in high performance TCP and multi-processor TCP
scalability, I
RW>> will disconnect netatm and dependent components from the build on
April 1,
RW>> 2006. At that point, I will merge updated socket and pcb reference
RW>> counting.
RW
RW>Reminder: April 1 approaches.
RW
RW>I've merged changes to many non-netinet protocols in support of the
RW>approaching socket/pcb reference model changes, but have the netinet
changes
RW>depend on completing socket layer changes that are believed not to work
with
RW>netatm as they stand. I'll be posting the socket and netinet changes to
RW>arch@ today; I've posted them previously to other lists, such as
current@.
Skip Ford expressed interest in netatm, but he said also that he would
continue to work on HARP even when it is removed. So I guess it could be
revived in the future (just in the case). I've also sent him my half -IDT
driver and he said he will first work on this. When this is ready we have
all the hardware supported in ngATM which HARP also does.
I have patches, and plan to commit them, that keep netatm compilable. The
problem is that I am unable to test netatm, and have limited time to try to
figure it out (and it's significant enough that it requires figuring out)..
|
I'd be moderatly suprised if it worked at all. None of the ATM code was fun
to deal with when I move struct ifnet out of the softc, but IIRC netatm way
by far the most confusing.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 |
|
| Back to top |
|
|
Bruce M Simpson
*nix forums beginner
Joined: 14 Aug 2003
Posts: 41
|
| Posted: Wed Mar 29, 2006 11:37 am Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, Mar 29, 2006 at 12:38:28PM +0200, Harti Brandt wrote:
| Quote: | Skip Ford expressed interest in netatm, but he said also that he would
continue to work on HARP even when it is removed. So I guess it could be
revived in the future (just in the case). I've also sent him my half -IDT
driver and he said he will first work on this. When this is ready we have
all the hardware supported in ngATM which HARP also does.
|
I have shipped IDT and ENI hardware to Skip which arrived as of last week.
BMS
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Wed Mar 29, 2006 11:13 am Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, 29 Mar 2006, Harti Brandt wrote:
| Quote: | On Wed, 29 Mar 2006, Robert Watson wrote:
RW>On Wed, 15 Mar 2006, Robert Watson wrote:
RW
RW>> In order to begin to merge revised socket/pcb code, required to fix a
RW>> number of current races manifesting in the TCP code under load, and
RW>> required for breaking out the tcbinfo lock which is a significant
RW>> bottleneck in high performance TCP and multi-processor TCP scalability, I
RW>> will disconnect netatm and dependent components from the build on April 1,
RW>> 2006. At that point, I will merge updated socket and pcb reference
RW>> counting.
RW
RW>Reminder: April 1 approaches.
RW
RW>I've merged changes to many non-netinet protocols in support of the
RW>approaching socket/pcb reference model changes, but have the netinet changes
RW>depend on completing socket layer changes that are believed not to work with
RW>netatm as they stand. I'll be posting the socket and netinet changes to
RW>arch@ today; I've posted them previously to other lists, such as current@.
Skip Ford expressed interest in netatm, but he said also that he would
continue to work on HARP even when it is removed. So I guess it could be
revived in the future (just in the case). I've also sent him my half -IDT
driver and he said he will first work on this. When this is ready we have
all the hardware supported in ngATM which HARP also does.
|
I have patches, and plan to commit them, that keep netatm compilable. The
problem is that I am unable to test netatm, and have limited time to try to
figure it out (and it's significant enough that it requires figuring out).
There are really two sticking points with it remaining in the tree right now:
(1) It's not MPSAFE, and in absence of a maintainer is unlikely to become so.
This means it is a direct obstacle to removing the non-MPSAFEty crutches
in the network stack, which we're otherwise increasingly done with. The
other components with similar problems will be facing similar eviction
notices if they don't have maintainers.
(2) Continuing work to improve SMP performance requires significant changes to
the socket code (and other parts of the stack). Each change in itself is
relatively minor, but requires non-trivial protocol adaptation and
testing. In absense of a maintainer for netatm, this work will either
break netatm, or be unable to proceed.
I can keep hacking on netatm to keep it compiling, but I can't promise the
result will work, and given the complexity of the socket and protocol code,
it's highly likely that it won't work. Rather than break it further and
further, I'd rather either find a maintainer, or mark it as deprecated and on
the removal path. The April 1 date is simply the date where the fact that I
cannot test netatm no longer becomes a blocking factor for my committing
changes that may break it, since otherwise these changes, and the changes
dependent on them, won't have time to settle out before we reach 7.0,
effectively stalling all further work along these lines, which is undesirable
 .
The April 1 date is also only for disabling the compile and marking it as
being on the removal path. The plan is not to remove it until late in the
summer, and only then if it hasn't been fixed to work in the new world order
or and shows no signs of moving in that direction. If there is significant
progress, plans are easy to change.
So all that aside, I continue to plan to commit my changes on April 1, but
welcome any work to keep netatm working. It sounds like bluetooth may also
briefly break; I've exchanged e-mail with emax and he has plans to fix it
shortly thereafter.
Robert N M Watson
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Harti Brandt
*nix forums addict
Joined: 24 Jun 2002
Posts: 62
|
| Posted: Wed Mar 29, 2006 10:38 am Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, 29 Mar 2006, Robert Watson wrote:
RW>On Wed, 15 Mar 2006, Robert Watson wrote:
RW>
RW>> In order to begin to merge revised socket/pcb code, required to fix a
RW>> number of current races manifesting in the TCP code under load, and
RW>> required for breaking out the tcbinfo lock which is a significant
RW>> bottleneck in high performance TCP and multi-processor TCP scalability, I
RW>> will disconnect netatm and dependent components from the build on April 1,
RW>> 2006. At that point, I will merge updated socket and pcb reference
RW>> counting.
RW>
RW>Reminder: April 1 approaches.
RW>
RW>I've merged changes to many non-netinet protocols in support of the
RW>approaching socket/pcb reference model changes, but have the netinet changes
RW>depend on completing socket layer changes that are believed not to work with
RW>netatm as they stand. I'll be posting the socket and netinet changes to
RW>arch@ today; I've posted them previously to other lists, such as current@.
Skip Ford expressed interest in netatm, but he said also that he would
continue to work on HARP even when it is removed. So I guess it could be
revived in the future (just in the case). I've also sent him my half -IDT
driver and he said he will first work on this. When this is ready we have
all the hardware supported in ngATM which HARP also does.
harti
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Wed Mar 29, 2006 10:07 am Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, 15 Mar 2006, Robert Watson wrote:
| Quote: | In order to begin to merge revised socket/pcb code, required to fix a number
of current races manifesting in the TCP code under load, and required for
breaking out the tcbinfo lock which is a significant bottleneck in high
performance TCP and multi-processor TCP scalability, I will disconnect
netatm and dependent components from the build on April 1, 2006. At that
point, I will merge updated socket and pcb reference counting.
|
Reminder: April 1 approaches.
I've merged changes to many non-netinet protocols in support of the
approaching socket/pcb reference model changes, but have the netinet changes
depend on completing socket layer changes that are believed not to work with
netatm as they stand. I'll be posting the socket and netinet changes to arch@
today; I've posted them previously to other lists, such as current@.
Robert N M Watson
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
George V. Neville-Neil
*nix forums beginner
Joined: 17 Mar 2006
Posts: 3
|
| Posted: Fri Mar 17, 2006 1:28 am Post subject:
Re: KAME/Fast IPSEC (was Re: netatm: plan for removal unless an active maintainer is found)
|
|
|
At Thu, 16 Mar 2006 08:36:19 +0000 (UTC),
Bjoern A. Zeeb wrote:
| Quote: | with hopefully enough time this problem will be solved during
the year. This will also need some netinet6 work,...
What you can find at
http://sources.zabbadoz.net/freebsd/ipv6/
is far from being complete or fully up-to-date but it's a start...
|
Sorry to chime in late, server upgrade.
We (Bjoern, myself and a few others) are actively working on this. I
am working first to make the system work in this way:
1) INET6: Kame IPv6, no IPSec
2) INET6 + IPSEC: Pure Kame IPv6 and IPSec
3) FAST_IPSEC: v4 Fast IPSec
4) INET6 + FAST_IPSEC: Kame v6 + FAST IPsec v4 and v6
That is we will be able to use Kame IPv6 with either Kame IPSec or
FAST_IPSEC.
The long term goal is to have only one set of code for IPv6 and for
IPSec, but that is going to take a bit more work.
I have started the changes to make 4 possible in a p4 branch. For
those with access look at branches marked fast_ipsec.
I want to do a lot of testing on this before putting it into CVS and
even though there is the TAHI test framework testing takes a while and
I want to try this with some more complex real networks.
Help, of course, is always appreciated ;-)
If anyone wants to be on my "little list of concerned parties" send me
your email and I'll try to send out regular patches and mails.
Later,
George
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Hans Petter Selasky
*nix forums beginner
Joined: 15 Mar 2006
Posts: 5
|
| Posted: Thu Mar 16, 2006 6:56 pm Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wednesday 15 March 2006 21:31, Hans Petter Selasky wrote:
I have tested my ISDN4BSD driver on a Sparc64 using NetBSD, and the driver
that is in SVN works. Not the one I released. That means all alignment and
endian issues have been resolved, and I now better understand how to write
portable code. However I would also like to test on a Sparc64 using FreeBSD
6.1? Anyone that wants to do some testing or debugging for me?
--HPS
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Bjoern A. Zeeb
*nix forums beginner
Joined: 05 May 2004
Posts: 10
|
| Posted: Thu Mar 16, 2006 8:36 am Post subject:
Re: KAME/Fast IPSEC (was Re: netatm: plan for removal unless an active maintainer is found)
|
|
|
On Thu, 16 Mar 2006, Massimo Lusetti wrote:
Hi,
| Quote: | On Wed, 2006-03-15 at 22:59 +0100, Pawel Jakub Dawidek wrote:
Let me add my two cents. There are actually two things to do with KAME
IPsec: MPSAFE and crypto(9) support and only one thing (IPv6) in case of
fast_ipsec(4), so I think it will be much easier to add IPv6 support to
fast_ipsec(4) and just drop KAME IPsec, so we can have one, full
functional IPsec stack.
This is really confusing for the users. When I first heard of
fast_ipsec(4) I thought it only works with crypto HW and if I need to do
cryptography in software I need KAME IPsec.
But that's just an opinion of a passive observer:)
I also would like to see more clearness on this, Pawel is right saying
it's a confusing situation.
|
with hopefully enough time this problem will be solved during
the year. This will also need some netinet6 work,...
What you can find at
http://sources.zabbadoz.net/freebsd/ipv6/
is far from being complete or fully up-to-date but it's a start...
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Massimo Lusetti
*nix forums beginner
Joined: 23 Sep 2005
Posts: 2
|
| Posted: Thu Mar 16, 2006 8:05 am Post subject:
KAME/Fast IPSEC (was Re: netatm: plan for removal unless an active maintainer is found)
|
|
|
On Wed, 2006-03-15 at 22:59 +0100, Pawel Jakub Dawidek wrote:
| Quote: | Let me add my two cents. There are actually two things to do with KAME
IPsec: MPSAFE and crypto(9) support and only one thing (IPv6) in case of
fast_ipsec(4), so I think it will be much easier to add IPv6 support to
fast_ipsec(4) and just drop KAME IPsec, so we can have one, full
functional IPsec stack.
This is really confusing for the users. When I first heard of
fast_ipsec(4) I thought it only works with crypto HW and if I need to do
cryptography in software I need KAME IPsec.
But that's just an opinion of a passive observer:)
|
I also would like to see more clearness on this, Pawel is right saying
it's a confusing situation.
Ciao
--
Massimo
There are more way to do things, one is the bsd-way the others are wrong
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Bruce M Simpson
*nix forums beginner
Joined: 14 Aug 2003
Posts: 41
|
| Posted: Thu Mar 16, 2006 2:52 am Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, Mar 15, 2006 at 09:18:01AM +0100, Harti Brandt wrote:
| Quote: | I'm all for this removal. The only two reasons for carrying this around is
that it supports CLIP over SVCs and that the driver for the IDT77211 chips
is HARP-only. I have half of an ngatm driver for these chips and sent them
out two at least two people during the last two years, but never heard
back. I have also code for CLIP over SVCs but due to ENOTIME was not yet
able to make this commit ready. If anybody knows somebody who could finish
the driver it would be great. The CLIP stuff is not so critical - almost
all people use PVCs only.
|
I am one such guilty party. Sadly my time has been completely consumed.
I second the removal of netatm.
BMS
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Pawel Jakub Dawidek
*nix forums addict
Joined: 24 Jun 2003
Posts: 92
|
| Posted: Wed Mar 15, 2006 9:59 pm Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
On Wed, Mar 15, 2006 at 10:54:40AM +0000, Robert Watson wrote:
+> Otherwise, with the exception of KAME IPSEC, the network stack code is actually in pretty good shape for removing the Giant compat shims. We've had at least a couple of
+> people say they're willing to work on this and take steps in the right direction (including some initial patches for IPSEC improvement), but I guess we'll see come August
+> whether it has happened. The discussion has always been about whether it's better to add IPv6 support to FAST_IPSEC, or lock down KAME IPSEC. Both are desirable, and both
+> require significant familiarity with the code and protocols involved.
Let me add my two cents. There are actually two things to do with KAME
IPsec: MPSAFE and crypto(9) support and only one thing (IPv6) in case of
fast_ipsec(4), so I think it will be much easier to add IPv6 support to
fast_ipsec(4) and just drop KAME IPsec, so we can have one, full
functional IPsec stack.
This is really confusing for the users. When I first heard of
fast_ipsec(4) I thought it only works with crypto HW and if I need to do
cryptography in software I need KAME IPsec.
But that's just an opinion of a passive observer:)
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am! |
|
| Back to top |
|
|
Hans Petter Selasky
*nix forums beginner
Joined: 15 Mar 2006
Posts: 5
|
| Posted: Wed Mar 15, 2006 8:31 pm Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
Hi,
Thanks for CC'ing me. I cannot subscribe to all the mailing lists around :-)
On Wednesday 15 March 2006 19:03, M. Warner Losh wrote:
| Quote: | In message: <20060315185803.1956114c@Magellan.Leidinger.net
Alexander Leidinger <Alexander@Leidinger.net> writes:
: Am Wed, 15 Mar 2006 10:29:03 -0700 (MST)
:
: schrieb "M. Warner Losh" <imp@bsdimp.com>:
: > : > now available to work on the capi integration, and hopefully will
: > : > do the SMP safety work as part of that. If not, it's also on the
: > : > chopping block. It's a significant piece of otherwise unmaintained
: > : > code, and something that's not trivially testable (at least, not by
: > : > me or anyone I've talked to lately . I don't want to see it
: > : > leave the tree, but it needs to be updated so that it can run
: > : > MPSAFE before 7.0.
: > :
: > : I may add, that Hans-Petter Selasky has a MPSAFE replacement (written
: > : from scratch it seems) for I4B (AFAIK including capi) and the USB
: > : stack. I have tested or reviewed neither of them, but as far as I can
: > : read in the mailinglists, he adresses not only the issues you mention
: > : here, but he also provides bugfixes and additional features compared
: > : to our current code base.
:
: > The problem is that this code isn't busdma safe at the moment. It was
: > posted for review on the NetBSD lists and this was the biggest set of
: > comments on tech-kern@netbsd.org. Since it isn't busdma safe, we'd
: > lose usb on sparc64 (and maybe arm) when this code is brought into the
: > tree. There have also been signficant concerns about the locking
: > that's done in the code as well, but I've not reviewed it recently.
|
Again, all USB drivers are driven like if 32-bit addressing is used. Actually
the issue was about a function having "u_int32_t" as return type or
"bus_size_t". I will change that.
| Quote: | :
: > There's been a lot of work done here, and that work is generally good,
: > but last time I looked at the code it wasn't ready to be integrated to
: > the tree.
|
Yes, right. I am still working on the USB system, but I am only one person,
and I really could need some help.
| Quote: | :
: The questions are:
: - What's less work to do?
: - Is there someone who is willing to do the work?
Agreed. Hans-Petter's work has great potential, but I think someone
with a lot of time and knowledge of FreeBSD specific issues is going
to need to work with him to properly integrate it into the tree. It
isn't a drop in right now, but could be with some work.
If usb abd usbHPS can co-exist in the tree, we might be able to do
some of this in-tree. But usb is a very important subsystem and
transitioning to a new code base is a high-risk thing.
|
I would suggest that we freeze "/sys/dev/usb" or make a copy of it. Then we [a
few people] start moving all USB device drivers over to the new USB API,
which will end up under "/sys/dev/usb2". Sure this can be in the tree. Then
if people want to activate it, they have to run, maybe something like:
cd /sys/dev/usb2
make package S=src.temp # maybe this is not needed if all the
# files are in place
make install
Or we can just use my SVN account at turbocat.net.
--HPS
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
M. Warner Losh
*nix forums Guru
Joined: 22 Mar 2002
Posts: 365
|
| Posted: Wed Mar 15, 2006 6:06 pm Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
In message: <20060315104037.J5861@fledge.watson.org>
Robert Watson <rwatson@FreeBSD.org> writes:
: Would it make sense
: for us to set a similar set of date deadlines for non-MPSAFE drivers? I.e.,
: August 2006 for removing them from the build, and October, 2006, for remove
: from the CVS HEAD? I suspect in that time several of the above will get
: updated.
I think this only makes sense if we can solve the usb issue in that
time frame. We could make it the deadline for non-usb drivers.
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
M. Warner Losh
*nix forums Guru
Joined: 22 Mar 2002
Posts: 365
|
| Posted: Wed Mar 15, 2006 6:03 pm Post subject:
Re: netatm: plan for removal unless an active maintainer is found
|
|
|
In message: <20060315185803.1956114c@Magellan.Leidinger.net>
Alexander Leidinger <Alexander@Leidinger.net> writes:
: Am Wed, 15 Mar 2006 10:29:03 -0700 (MST)
: schrieb "M. Warner Losh" <imp@bsdimp.com>:
:
: > : > now available to work on the capi integration, and hopefully will do
: > : > the SMP safety work as part of that. If not, it's also on the
: > : > chopping block. It's a significant piece of otherwise unmaintained
: > : > code, and something that's not trivially testable (at least, not by
: > : > me or anyone I've talked to lately . I don't want to see it leave
: > : > the tree, but it needs to be updated so that it can run MPSAFE before
: > : > 7.0.
: > :
: > : I may add, that Hans-Petter Selasky has a MPSAFE replacement (written from
: > : scratch it seems) for I4B (AFAIK including capi) and the USB stack. I have
: > : tested or reviewed neither of them, but as far as I can read in the
: > : mailinglists, he adresses not only the issues you mention here, but he also
: > : provides bugfixes and additional features compared to our current code base.
: >
: > The problem is that this code isn't busdma safe at the moment. It was
: > posted for review on the NetBSD lists and this was the biggest set of
: > comments on tech-kern@netbsd.org. Since it isn't busdma safe, we'd
: > lose usb on sparc64 (and maybe arm) when this code is brought into the
: > tree. There have also been signficant concerns about the locking
: > that's done in the code as well, but I've not reviewed it recently.
: >
: > There's been a lot of work done here, and that work is generally good,
: > but last time I looked at the code it wasn't ready to be integrated to
: > the tree.
:
: The questions are:
: - What's less work to do?
: - Is there someone who is willing to do the work?
Agreed. Hans-Petter's work has great potential, but I think someone
with a lot of time and knowledge of FreeBSD specific issues is going
to need to work with him to properly integrate it into the tree. It
isn't a drop in right now, but could be with some work.
If usb abd usbHPS can co-exist in the tree, we might be able to do
some of this in-tree. But usb is a very important subsystem and
transitioning to a new code base is a high-risk thing.
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
