On 10/21/2015 9:51 AM, Christoph Hellwig wrote:
We have a UAPI that requires us to keep the device query verb for ever, and
hence the returned device attr struct, it would be a much smaller and noisy
patch pointer
to cache an device attr on the device structure.
Take a look at the code. The only time we ever call into ->query_device is
for the userspace only timestamping extensions only implemented for mlx4.
We will have many more device query extensions, but the point I tried to
make here is a bit different --
we do need to keep the user/kernel device attr struct as part of the
UAPI, and don't see any reason to
avoid it in the kernel, just because some other subsystems do that,
according to your view. As I said, you
would have to work real (real) hard to convince the networking ppl to
add fields to struct net_device sk_buff
and friends... the nature of rdma/offloading is such that new attr come
often and I don't think we need
to touch our device struct every release.
With all the stuff we have on the plate the kernel API will look substatially
different from the arkane 'Verbs' implementation in userspace, and they will
use less and less common code. Libuvers and the ABIs it uses are something
we can't change unfortunately, but we can make the kernel API much much
better by learining lessons from other kernel subsystems. That's work
that Jason Sagi and me have been doing for a while.
I'd also suggest you update your Linux knowledge before trying to
micromanage patch submissions.
not trying to micro-manage @ all, I went over the archives and haven't
found any review or ack
to your giant patch that touches the whole subsystem (drivers, core and
ULPs) expect from Sagi's
-- lets hear more opinions. Re my education -- can you make the argument
more precise: what are we
making much much better in the kernel API by thins house moving exercise?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
