Re: [PATCH 06/24] tools headers uapi: Sync linux/usbdevice_fs.h with the kernel sources

[Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>]

Em Tue, Oct 01, 2019 at 09:59:55AM -0400, Alan Stern escreveu:
> On Tue, 1 Oct 2019, Arnaldo Carvalho de Melo wrote:
> 
> > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> > 
> > To pick up the changes from:
> > 
> >   4ed3350539aa ("USB: usbfs: Add a capability flag for runtime suspend")
> >   7794f486ed0b ("usbfs: Add ioctls for runtime power management")
> > 
> > This triggers these changes in the kernel sources, automagically
> > supporting these new ioctls in the 'perf trace' beautifiers.
> > 
> > Soon this will be used in things like filter expressions for tracepoints
> > in 'perf record', 'perf trace', 'perf top', i.e. filter expressions will
> > do a lookup to turn things like USBDEVFS_WAIT_FOR_RESUME into _IO('U',
> > 35) before associating the tracepoint expression to tracepoint perf
> > event.
> > 
> >   $ tools/perf/trace/beauty/usbdevfs_ioctl.sh  > before
> >   $ cp include/uapi/linux/usbdevice_fs.h tools/include/uapi/linux/usbdevice_fs.h
> >   $ git diff
> >   diff --git a/tools/include/uapi/linux/usbdevice_fs.h b/tools/include/uapi/linux/usbdevice_fs.h
> >   index 78efe870c2b7..cf525cddeb94 100644
> >   --- a/tools/include/uapi/linux/usbdevice_fs.h
> >   +++ b/tools/include/uapi/linux/usbdevice_fs.h
> >   @@ -158,6 +158,7 @@ struct usbdevfs_hub_portinfo {
> >    #define USBDEVFS_CAP_MMAP                      0x20
> >    #define USBDEVFS_CAP_DROP_PRIVILEGES           0x40
> >    #define USBDEVFS_CAP_CONNINFO_EX               0x80
> >   +#define USBDEVFS_CAP_SUSPEND                   0x100
> > 
> >    /* USBDEVFS_DISCONNECT_CLAIM flags & struct */
> > 
> >   @@ -223,5 +224,8 @@ struct usbdevfs_streams {
> >     * extending size of the data returned.
> >     */
> >    #define USBDEVFS_CONNINFO_EX(len)  _IOC(_IOC_READ, 'U', 32, len)
> >   +#define USBDEVFS_FORBID_SUSPEND    _IO('U', 33)
> >   +#define USBDEVFS_ALLOW_SUSPEND     _IO('U', 34)
> >   +#define USBDEVFS_WAIT_FOR_RESUME   _IO('U', 35)
> > 
> >    #endif /* _UAPI_LINUX_USBDEVICE_FS_H */
> >   $ tools/perf/trace/beauty/usbdevfs_ioctl.sh  > after
> >   $ diff -u before after
> >   --- before	2019-09-27 11:41:50.634867620 -0300
> >   +++ after	2019-09-27 11:42:07.453102978 -0300
> >   @@ -24,6 +24,9 @@
> >    	[30] = "DROP_PRIVILEGES",
> >    	[31] = "GET_SPEED",
> >    	[32] = "CONNINFO_EX",
> >   +	[33] = "FORBID_SUSPEND",
> >   +	[34] = "ALLOW_SUSPEND",
> >   +	[35] = "WAIT_FOR_RESUME",
> >    	[3] = "RESETEP",
> >    	[4] = "SETINTERFACE",
> >    	[5] = "SETCONFIGURATION",
> >   $
> > 
> > This addresses the following perf build warning:
> > 
> >   Warning: Kernel ABI header at 'tools/include/uapi/linux/usbdevice_fs.h' differs from latest version at 'include/uapi/linux/usbdevice_fs.h'
> >   diff -u tools/include/uapi/linux/usbdevice_fs.h include/uapi/linux/usbdevice_fs.h
> 
> This may sound silly, and undoubtedly the question has been asked 
> before.  Nevertheless...
> 
> Why go to the time and trouble to detect differences between 
> tools/include/uapi/linux/usbdevice_fs.h and 
> include/uapi/linux/usbdevice_fs.h?  Why not just make the first a 
> symbolic link to the second?  Or get rid of the first entirely, and 
> change the source code so that it #include's the second?

We can't use anything from outside tools/perf/ to build it, sometimes
things get changed by kernel developers and tooling breaks.

Another reason is that we want to be able to do:

[acme@quaco perf]$ make help | grep perf
  perf-tar-src-pkg    - Build perf-5.3.0.tar source tarball
  perf-targz-src-pkg  - Build perf-5.3.0.tar.gz source tarball
  perf-tarbz2-src-pkg - Build perf-5.3.0.tar.bz2 source tarball
  perf-tarxz-src-pkg  - Build perf-5.3.0.tar.xz source tarball
[acme@quaco perf]$

Take that tarball, transfer it to an older system and still have it
building and working.

We also use the build warnings as hints that something needs to be
changed in tooling to pick up new kernel features, such as new ioctls,
syscall arguments to handle in 'perf trace', etc.

- Arnaldo