Re: [igt-dev] [PATCH i-g-t 2/4] lib/igt_device_scan: Make igt_device_scan independent from igt_core

Petri Latvala
2020-05-27T08:08:39Z

On Wed, May 27, 2020 at 10:48:42AM +0300, Arkadiusz Hiler wrote:
> On Tue, May 26, 2020 at 09:14:58AM -0700, Lucas De Marchi wrote:
> > On Tue, May 26, 2020 at 5:24 AM Arkadiusz Hiler
> > <arkadiusz.hiler@intel.com> wrote:
> > >
> > > From: Ayaz A Siddiqui <ayaz.siddiqui@intel.com>
> > >
> > > igt_device_scan can now be used as a separate library which only depends
> > > glib and libudev - some IGT internals are being stubbed in this case.
> > >
> > > Signed-off-by: Ayaz A Siddiqui <ayaz.siddiqui@intel.com>
> > > Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
> > > ---
> > > lib/Makefile.am | 8 ++++++-
> > > lib/drmtest.c | 1 +
> > > lib/igt_device_scan.c | 6 ++---
> > > lib/igt_device_scan.h | 8 ++++++-
> > > lib/igt_tools_stub.c | 51 +++++++++++++++++++++++++++++++++++++++++++
> > > lib/meson.build | 15 +++++++++++++
> > > 6 files changed, 83 insertions(+), 6 deletions(-)
> > > create mode 100644 lib/igt_tools_stub.c
> > >
> > > diff --git a/lib/Makefile.am b/lib/Makefile.am
> > > index fba7fcab..e9753d3c 100644
> > > --- a/lib/Makefile.am
> > > +++ b/lib/Makefile.am
> > > @@ -102,6 +102,12 @@ include Makefile.sources
> > >
> > > libintel_tools_la_SOURCES = $(lib_source_list)
> > >
> > > +libigt_device_scan_la_SOURCES = \
> > > + igt_list.c \
> > > + igt_tools_stub.c \
> > > + igt_device_scan.c \
> > > + igt_device_scan.h
> > > +
> > > libigt_perf_la_SOURCES = \
> > > igt_perf.c \
> > > igt_perf.h
> > > @@ -121,7 +127,7 @@ pkgconfig_DATA = i915-perf.pc
> > >
> > > lib_LTLIBRARIES = libi915_perf.la
> > >
> > > -noinst_LTLIBRARIES = libintel_tools.la libigt_perf.la
> > > +noinst_LTLIBRARIES = libintel_tools.la libigt_perf.la libigt_device_scan.la
> > > noinst_HEADERS = check-ndebug.h
> > >
> > > if !HAVE_LIBDRM_INTEL
> > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > index 70fd64c9..bced1453 100644
> > > --- a/lib/drmtest.c
> > > +++ b/lib/drmtest.c
> > > @@ -53,6 +53,7 @@
> > > #include "intel_io.h"
> > > #include "igt_debugfs.h"
> > > #include "igt_device.h"
> > > +#include "igt_params.h"
> > > #include "igt_gt.h"
> > > #include "igt_kmod.h"
> > > #include "igt_sysfs.h"
> > > diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
> > > index 7b0fc00e..be854b01 100644
> > > --- a/lib/igt_device_scan.c
> > > +++ b/lib/igt_device_scan.c
> > > @@ -22,11 +22,8 @@
> > > *
> > > */
> > >
> > > -#include "igt.h"
> > > -#include "igt_list.h"
> > > -#include "igt_sysfs.h"
> > > -#include "igt_device.h"
> > > #include "igt_device_scan.h"
> > > +#include "igt_list.h"
> > > #include <glib.h>
> > > #include <libudev.h>
> > > #include <linux/limits.h>
> > > @@ -34,6 +31,7 @@
> > > #include <sys/types.h>
> > > #include <dirent.h>
> > > #include <fcntl.h>
> > > +#include "igt_core.h"
> > >
> > > /**
> > > * SECTION:igt_device_scan
> > > diff --git a/lib/igt_device_scan.h b/lib/igt_device_scan.h
> > > index 24eafe62..ad632145 100644
> > > --- a/lib/igt_device_scan.h
> > > +++ b/lib/igt_device_scan.h
> > > @@ -26,7 +26,13 @@
> > > #define __IGT_DEVICE_SCAN_H__
> > >
> > > #include <limits.h>
> > > -#include <igt.h>
> > > +#include <stdbool.h>
> > > +#include <stdint.h>
> > > +#include <stdio.h>
> > > +#include <fcntl.h>
> > > +#include <unistd.h>
> > > +#include <getopt.h>
> > > +#include <errno.h>
> >
> > shouldn't these be sorted?
>
> It wouldn't hurt but kernel coding style doesn't mention header sorting.
> IGT doesn't enforce anything on top of it ¯\_(ツ)_/¯

If header include blocks are already sorted, keep them sorted, that's
the thumb rule I've used. That said, please use "header-from-igt.h"
and <header-from-system>.

>
> > > enum igt_devices_print_type {
> > > IGT_PRINT_SIMPLE,
> > > diff --git a/lib/igt_tools_stub.c b/lib/igt_tools_stub.c
> > > new file mode 100644
> > > index 00000000..9a0ec621
> > > --- /dev/null
> > > +++ b/lib/igt_tools_stub.c
> > > @@ -0,0 +1,51 @@
> > > +/*
> > > + * Copyright © 2020 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining a
> > > + * copy of this software and associated documentation files (the "Software"),
> > > + * to deal in the Software without restriction, including without limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the next
> > > + * paragraph) shall be included in all copies or substantial portions of the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> > > + * IN THE SOFTWARE.
> > > + *
> > > + */
> >
> > are we still in a mix of SPDX + full text?
>
> Only stubs and drm uapi seem to have SPDX identifiers as of now. Petri
> was researching the topic, I don't remember the conclusion.

Converting from a normal text block to SPDX is a no-no. Using SPDX for
new files is ok.

--
Petri Latvala