MIME-Version: 1.0
References: <20220105220653.122451-1-gwendal@chromium.org> <CAE_wzQ_DTnrU9QbADZuNyt4fszAiTwa04D9muC-xE_S3MM9eGQ@mail.gmail.com>
 <CAPUE2uu3FPvxHHGYGbckxR=QmWt3=KwFk3DYoqBSmaQd+AO0QA@mail.gmail.com> <20220106110558.49dd6f26@coco.lan>
In-Reply-To: <20220106110558.49dd6f26@coco.lan>
From:   Gwendal Grignou <gwendal@chromium.org>
Date:   Mon, 10 Jan 2022 01:31:23 -0800
Message-ID: <CAPUE2usF1m8rmE1_Nrdv_B5SfXExzKzGnhcZrmcSHFSMQzyjiw@mail.gmail.com>
Subject: Re: [PATCH 00/17] Add export symbol namespace PL_CHROMEOS
To:     Mauro Carvalho Chehab <mchehab@kernel.org>
Cc:     Dmitry Torokhov <dtor@chromium.org>, bleung@chromium.org,
        groeck@chromium.org, myungjoo.ham@samsung.com,
        cw00.choi@samsung.com, benjamin.tissoires@redhat.com,
        hverkuil-cisco@xs4all.nl, lee.jones@linaro.org,
        pmalani@chromium.org, sre@kernel.org, thierry.reding@gmail.com,
        u.kleine-koenig@pengutronix.de, lgirdwood@gmail.com,
        a.zummo@towertech.it, cychiang@chromium.org, perex@perex.cz,
        linux-kernel@vger.kernel.org, Jonathan Cameron <jic23@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jan 6, 2022 at 2:06 AM Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
>
> Em Wed, 5 Jan 2022 20:26:36 -0800
> Gwendal Grignou <gwendal@chromium.org> escreveu:
>
> > On Wed, Jan 5, 2022 at 2:58 PM Dmitry Torokhov <dtor@chromium.org> wrote:
> > >
> > > Hi Gwendal,
> > >
> > > On Wed, Jan 5, 2022 at 2:07 PM Gwendal Grignou <gwendal@chromium.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