linux-kernel - Re: [PATCH 00/17] Add export symbol namespace PL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPUE2usF1m8rmE1_Nrdv_B5SfXExzKzGnhcZrmcSHFSMQzyjiw@mail.gmail.com>
Date:   Mon, 10 Jan 2022 01:31:23 -0800
From:   Gwendal Grignou <gwendal@...omium.org>
To:     Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Dmitry Torokhov <dtor@...omium.org>, bleung@...omium.org,
        groeck@...omium.org, myungjoo.ham@...sung.com,
        cw00.choi@...sung.com, benjamin.tissoires@...hat.com,
        hverkuil-cisco@...all.nl, lee.jones@...aro.org,
        pmalani@...omium.org, sre@...nel.org, thierry.reding@...il.com,
        u.kleine-koenig@...gutronix.de, lgirdwood@...il.com,
        a.zummo@...ertech.it, cychiang@...omium.org, perex@...ex.cz,
        linux-kernel@...r.kernel.org, Jonathan Cameron <jic23@...nel.org>
Subject: Re: [PATCH 00/17] Add export symbol namespace PL_CHROMEOS

On Thu, Jan 6, 2022 at 2:06 AM Mauro Carvalho Chehab <mchehab@...nel.org> wrote:
>
> Em Wed, 5 Jan 2022 20:26:36 -0800
> Gwendal Grignou <gwendal@...omium.org> escreveu:
>
> > On Wed, Jan 5, 2022 at 2:58 PM Dmitry Torokhov <dtor@...omium.org> wrote:
> > >
> > > Hi Gwendal,
> > >
> > > On Wed, Jan 5, 2022 at 2:07 PM Gwendal Grignou <gwendal@...omium.org> wrote:
> > > >
> > > > Add a symbol namespace for functions exported by the plaform chromeos
> > > > subsystem.
> > >
> > > It would be great to explain why this is needed/desirable. What are
> > > the benefits of introducing this namespace? What problem are you
> > > trying to solve?
> > The issue came when reviewing an iio sensor
> > (https://www.spinics.net/lists/linux-iio/msg66280.html). I wanted to
> > be ahead of the curve (for once).
>
> Patch 01 should clearly document the reason why this is needed.
> Yet, see below.
>
> While I see value on using namespaces, we should have extra care when
> this is used for kAPIs designed for a product/system. I mean, what
> prevents that the affected drivers won't support some day different
> non-ChromeOS products? We have a media driver originally written to
> work with the One Laptop Per Children hardware, that used some
> product-specific kAPIs, that were extended a couple years later to
> cover different types of hardware.
>
> What happens if some day, a driver introduced to be used on a ChromeOS
> hardware would also be used by a non-ChromeOS hardware? This could
> become messy as times goes by.
>
> Instead, IMO, it would make sense to have per-subsystem namespaces.
> So, for instance, placing iio under an IIO-specific namespace
> (and the same for other subsystems) makes more sense on my
> eyes, as the namespace boundary will be clearer, and an IIO driver
> will always be IIO, no matter on what hardware such driver would
> be used.
I based this patchset on the current/future use in the IIO subsystem,
where the namespaces are used for small subsystem like HID,
IIO_HID_ATTRIBUTES, or code shared among sensors drivers of the same
vendor (LTC2497, more to come).
Since the usage of namespace in the kernel is not clearly defined yet,
I wait for the dust to settle and more usage to emerge before tuning
this patchset.

Thanks,
Gwendal.
>
> Thanks,
> Mauro