> What's the benefit here? Seems very risky at very little gain. > > The juice ain't worth the squeeze. NAK Hello, It is fair to argue that these changes are too tiny to be very meaningful for performance but the other goal of this patch was also to make the code look cleaner and easier for me and other people to understand. I hope that is a reasonable desire. It is not fair to argue that these changes are risky. If it is risky for a person to add code then the code is too complicated to understand and should be rewritten or tests or formal methods should be used to verify correctness. Are you suggesting that the mqueue subsystem is too complicated for one to understand changes made to it and that it needs to be cleaned up a bit? I am trying to make the code easier to understand with this patch. Or that you'd want some more testing of the mqueue subsystem or the changes I made too it? Or that you'd want some more formal methods to make the code easier to verify? I suppose the area of code use a few extra sparse annotations. Thank you, Steven Stewart-Gallus -- To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
