ofed merge soon
John Baldwin
jhb at freebsd.org
Fri Jan 28 22:06:32 UTC 2011
On Friday, January 28, 2011 3:56:30 pm Jeff Roberson wrote:
> On Fri, 28 Jan 2011, John Baldwin wrote:
>
> > On Thursday, January 27, 2011 9:59:01 pm Jeff Roberson wrote:
> >> Hi Folks,
> >>
> >> I am merging ofed very soon. Here is the diff between the ofed base and
> >> head branches, which includes all of the diffs to vendor files and FreeBSD
> >> files:
> >>
> >> http://people.freebsd.org/~jeff/ofed.diff
> >
> > Did you consider changing ndp to match the code from arp to print out the link
> > layer addresses? If you don't want to do that, should there be a constant
> > similar to ETHER_ADDR_LEN that is suitable for IB to avoid hardcoding '20' in
> > ndp? Here is the similar code from arp (which ndp probably should adopt in
> > some fashion):
> >
>
> You're right, I was lazy in ndp. Thanks for keeping me honest.
>
> > if (sdl->sdl_alen) {
> > if ((sdl->sdl_type == IFT_ETHER ||
> > sdl->sdl_type == IFT_L2VLAN ||
> > sdl->sdl_type == IFT_BRIDGE) &&
> > sdl->sdl_alen == ETHER_ADDR_LEN)
> > printf("%s", ether_ntoa((struct ether_addr
> > *)LLADDR(sdl)));
> > else {
> > int n = sdl->sdl_nlen > 0 ? sdl->sdl_nlen + 1 : 0;
> >
> > printf("%s", link_ntoa(sdl) + n);
> > }
> > } else
> > printf("(incomplete)");
> >
> >> The diffs are actually quite small when you eliminate ofed diffs. I don't
> >> know why I have so many merge properties but I'll just apply this diff to
> >> current, build & test before committing rather than have svn do it.
> >> Unless someone tells me otherwise.
> >
> > Just applying the diffs is probably fine.
> >
> > Also, at some point I would probably like to rename intr_drain() or hide it in
> > some way so that only ofed uses it. FreeBSD drivers should drain interrupt
> > handlers, not IRQs. I realize the ofed Linux compat shims are stuck with that
> > interface, but for FreeBSD drivers I want a proper interface.
>
> Any suggestions? Is there a proper interface available yet? The
> implementation I have requires internals that are not exposed outside of
> kern_intr.c so it has to live there.
I think it will have to live there always, yes. Hmm, for now maybe just add
a comment to say that it is only for Linux compat currently and not a
supported interface. When I add a different drain interface I will make sure
this function has the same semantics.
--
John Baldwin
More information about the freebsd-arch
mailing list