On Sat, Sep 10, 2016 at 06:14:42PM +0200, Christoph Hellwig wrote:
> OFVWG meetings have absolutely zero relevance for Linux development.
Well, to be fair there are a fair number of kernel developers on that
particular call..
> More "flexibility" for drivers just means giving up on designing a
> coherent API and leaving it to drivers authors to add crap to their
> own drivers. That's a major step backwards.
Sadly, it isn't a step backwards, it is status quo - at least as far
as the uapi is concerned.
Every single user space driver has its own private abi file, carefully
hidden in their driver, and dutifully copied over to user space:
providers/cxgb3/iwch-abi.h
providers/cxgb4/cxgb4-abi.h
providers/hfi1verbs/hfi-abi.h
providers/i40iw/i40iw-abi.h
providers/ipathverbs/ipath-abi.h
providers/mlx4/mlx4-abi.h
providers/mlx5/mlx5-abi.h
providers/mthca/mthca-abi.h
providers/nes/nes-abi.h
providers/ocrdma/ocrdma_abi.h
providers/rxe/rxe-abi.h
Just to pick two random examples:
struct mlx5_create_cq {
struct ibv_create_cq ibv_cmd;
__u64 buf_addr;
__u64 db_addr;
__u32 cqe_size;
};
struct iwch_create_cq {
struct ibv_create_cq ibv_cmd;
uint64_t user_rptr_addr;
};
Love to hear ideas on a way forward that doesn't involve rewriting
everything :(
> They should not be using the code in drivers/infiniband. usnic is such
> an example of a driver that should never have been added in it's current
> form.
+1
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
