lkml.org 
[lkml]   [2006]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [openib-general] Re: [PATCH 9 of 18] ipath - char devices for diagnostics and lightweight subnet management
From
Date
> I'm
> talking about all the kernel code like the following (and similar
> stuff for guidinfo, nodedescription, portinfo, pkeytable).
>
> You must have nearly identical code in your userspace SMA, since it
> also has to respond to the same SM queries, right?
>
> I'm trying to understand why you can't get down to one implementation
> of these functions.

Why does that make a difference? The way I see it, we handle MAD
packets by either diverting them somewhere or passing them through the
normal ib_mad channel. We divert them somewhere because we find it
convenient to do so: it allows us to provide an SMA to our customers
without them having to have the full IB stack running. The SMA we
provide for these circumstances runs in userspace. It doesn't make use
of the existing ipath_mad.c code because that's tailored to: 1) run in
the kernel; and 2) deal with the IB stack. Even if we ripped out the
guts of ipath_mad.c and had it pass the requests to the userspace SMA,
we'd still have to have the diversion path in there for cases where the
IB stack isn't around.

--
Robert Walsh Email: rjwalsh@pathscale.com
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-24 04:04    [W:0.101 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site