On Tue, May 15, 2018 at 04:02:55PM +0100, James Simmons wrote: > > > /* > > > * Allocate new object. This may result in rather complicated > > > * operations, including fld queries, inode loading, etc. > > > */ > > > o = lu_object_alloc(env, dev, f, conf); > > > - if (IS_ERR(o)) > > > + if (unlikely(IS_ERR(o))) > > > return o; > > > > > > > This is an unrelated and totally pointless. likely/unlikely annotations > > hurt readability, and they should only be added if it's something which > > is going to show up in benchmarking. lu_object_alloc() is already too > > slow for the unlikely() to make a difference and anyway IS_ERR() has an > > unlikely built in so it's duplicative... > > Sounds like a good checkpatch case to test for :-) Some people like to try > and milk ever cycle they can. Personally for me I never use those > annotations. With modern processors I'm skeptical if their benefits. > I do cleanup up the patches to some extent to make it compliant with > kernel standards but leave the core code in place for people to comment > on. > > > Anyway, I understand that Intel has been ignoring kernel.org instead of > > sending forwarding their patches properly so you're doing a difficult > > and thankless job... Thanks for that. I'm sure it's frustrating to > > look at these patches for you as well. > > Thank you for the complement. Also thank you for taking time to review > these patches. Your feedback is most welcomed and benefitical to the > health of the lustre client. > > Sadly its not just Intel but other vendors that don't directly contribute > to the linux lustre client. I have spoke to the vendors about contributing > and they all say the same thing. No working with drivers in the staging > tree. Sadly all the parties involved are very interested in the success > of the lustre client. No one has ever told me directly why they don't get > involved but I suspect it has to deal with 2 reasons. One is that staging > drivers are not normally enabled by distributions so their clients > normally will never deal with the staging lustre client. Secondly vendors > just lack the man power to contribute in a meanful way. If staging is hurting you, why is it in staging at all? Why not just drop it, go off and spend a few months to clean up all the issues in your own tree (with none of those pesky requirements of easy-to-review patches) and then submit a "clean" filesystem for inclusion in the "real" part of the kernel tree? It doesn't sound like anyone is actually using this code in the tree as-is, so why even keep it here? thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
