On Mon, 2017-10-16 at 22:57 +0300, Michael S. Tsirkin wrote: > On Mon, Oct 16, 2017 at 10:26:33AM -0700, Bart Van Assche wrote: > > I think that this shows that the followed approach does not work, > > probably because several driver authors do not use sparse. For > > developers who are not the authors of these drivers it would take > > a very significant effort to make these drivers endianness clean. > > I'm afraid I still don't see it. For developers endian-ness is really > easy. Look at hardware spec make sure code matches. You can often do > without looking at the spec too, if a given field is always used with > cpu_to_le, mark it __le. If you don't want to change driver code, you > don't really need to run sparse on it. You seem to assume that all drivers that are not yet endianness clean do not contain any endianness conversion bugs. I severely doubt that that assumption is correct. It is likely that it is not possible to make several kernel drivers endianness clean due to endianness conversion bugs in such drivers. > > Examples are drivers/scsi/qla2xxx and drivers/infiniband/hw/nes. > > These seem to be actively maintained. So post a patch, maintainers > can look at the spec to help make sure annotations are right. I don't have the time to delve deep in these two and the many other kernel drivers that are not endianness clean. So please stop telling *me* that *I* have to fix the endianness annotations in these drivers. BTW, I think it should be mentioned here that you have tried to fix the endianness annotations in the qla2xxx driver but once you noticed how complicated that task was that you gave up half-way. See also Michael Tsirkin, [PATCH] scsi/qla2xxx: label endian-ness for many fields, 9 Dec 2016 (https://www.spinics.net/lists/linux-scsi/msg102739.html). > > Hence restore the ability to disable sparse endianness checks such > > that it becomes again easy to review other sparse diagnostics for > > people who want to analyze drivers they are not the author of. > > What are these diagnostics that are important to analyze? E.g. a spin_unlock() that is missing from an error path. Sparse can detect such errors. > White-listing these as opposed to black-listing endian-ness might be a > better idea. As explained in a previous e-mail, any approach that suppresses endianness error messages automatically makes it easier for driver authors to ignore endianness error messages. This is why I prefer that if endianness error messages are suppressed that this happens manually. Hence the patch at the start of this e-mail thread that restores __CHECK_ENDIAN__. Bart.��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
