Re: [openib-general] Re: [PATCH 9 of 18] ipath - char devices for diagnostics and lightweight subnet management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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: [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux