On Wed, Oct 21, 2015 at 09:44:41AM +0300, Or Gerlitz wrote: > Fact is that for struct net_device you will not add 333 new fields over > night in the coming 33 years, for sure.
That's because they never had this split and added fields to struct netdev as required. One interesting difference in netdev is that it move all the function pointers out to a different structure so it could be kept const. This introduces one more level of pointer chasing but has other advantages. > This makes much sense to me, as a guideline. I don't think we should have a > device structure with the current > 100 fields and another few hundreds without any notable benefit and against > the common practice in the networking > subsystem. Please understand the networking subsystem (or SCSI, or NVMe, or ...) before making such incorrect comments. We're moving towards how all other subsystems work. > 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 to cache an device attr pointer > 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. 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. -- 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
