Re: [Ksummit-discuss] [TECH TOPIC] How to encourage driver authors to annotate integer endianness properly

[Bart Van Assche <Bart.VanAssche@wdc.com>]

On Wed, 2017-10-25 at 11:54 +0200, Greg KH wrote:
> On Wed, Oct 25, 2017 at 09:47:25AM +0000, Bart Van Assche wrote:
> > Hello Ted,
> > 
> > As you most likely know endianness annotations like __be32 can be verified
> > by the static source code analyzer called sparse. These annotations are a
> > big help to verify whether endianness conversions in drivers are correct
> > (e.g. be32_to_cpu()). However, many driver authors either are not familiar
> > with sparse or do not use it to verify their work. I think we need a way
> > to encourage driver authors to pay attention to endianness annotations,
> > e.g. by letting the zero-day kernel test infrastructure verify endianness
> > annotations. Please consider to add this topic to the kernel summit agenda. 
> 
> Driver subsystem maintainers should know this, and sparse reports should
> be simple to run and notice these issues.  If you know of a subsystem
> that is not paying attention to this, please let those maintainers know
> and send patches to resolve the issues :)

Hi Greg,

A significant challenge is that for several drivers (e.g. drivers/scsi/qla2xxx
and drivers/infiniband/hw/nes) fixing the endianness annotations is so hard
that only the driver authors can make these drivers endianness clean. Three
challenges that have been encountered while trying to make drivers endianness
clean are:
- Some driver authors use a single variable to store both cpu-endian and big
  endian data.
- Endianness bugs - using a big endian integer where a cpu endian number
  should have been used or vice versa.
- The definitive resource for the endianness format is the firmware
  documentation. For many kernel drivers the firmware documentation is either
  not available or only available under NDA.

Bart.