Re: [openib-general] Re: [PATCH 0 of 18] ipath driver - for inclusion in 2.6.17

On Fri, 2006-03-24 at 15:21 -0800, Roland Dreier wrote:

Clearly the simplest solution for your
situation is just to kill it.

Yes, I'll do that.

We seem to be going around and around on this. There definitely is
duplicated code; you just hide some of it in userspace. You clearly
have two copies of the function to generate a reply to a GET of
NodeInfo, for example.

That's true. What I'm not so clear on is why you care that we have a
similar facility in userland. The userland SMA is so simple, we haven't
had to touch it in a long time, except to use the new ioctl-free ABI.
There's negligible duplicated coding effort going on.

What if you moved the MAD query handling code into your core driver?
You could use your current method of sending and receiving replies
directly when ib_ipath isn't loaded, but just process the queries in
the kernel without proxying to userspace. Then if/when QP0 is
created, switch to letting the MAD layer handle sending and receiving
queries and let it call the same query handling code via your
process_mad method.

But it would (I think) solve all the issues of needing ib_mad loaded
for things to work. Users could even load ib_ipath without ib_mad and
have IB verbs work -- anything that actually needed MADs would pull in
ib_mad as a dependency, and everything else should work fine with the
SMA stuff handled by your driver.

I'll have to chew over this for a bit with a few other people. I'm not
actually trying to be difficult; it's just that changing the SMA at this
point is quite disruptive. we have schedules to muck with, plans to
accelerate, people to reallocate, and the like.

It would be a huge relief to me to be able to simply merge what we have
with the understanding that we'll resolve the SMA issue to your liking
as soon as possible, but you're the gatekeeper.

I understand that you really, really want your driver in 2.6.17.

Very much.

Also, in my opinion, we can still merge ipath
even after 2.6.17-rc1, since it doesn't touch anything (except trivial
kbuild stuff) outside of drivers/infiniband/hw/ipath.

I hope you're right.

<b

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

Relevant Pages