linux-kernel - Re: [PATCH] platform/x86: int3472: make common part a separate module

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHp75VfDPuQWGJO3GU2cG8a9Pq9BY8LL2xvGdyvKhmSa6_0EvA@mail.gmail.com>
Date: Wed, 29 May 2024 17:53:28 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Arnd Bergmann <arnd@...nel.org>, Daniel Scally <djrscally@...il.com>, 
	Hans de Goede <hdegoede@...hat.com>, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] platform/x86: int3472: make common part a separate module

On Wed, May 29, 2024 at 5:48 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Wed, May 29, 2024, at 16:28, Andy Shevchenko wrote:
> > On Wed, May 29, 2024 at 5:14 PM Arnd Bergmann <arnd@...db.de> wrote:
> >> On Wed, May 29, 2024, at 15:41, Andy Shevchenko wrote:
> >> > On Wed, May 29, 2024 at 12:50 PM Arnd Bergmann <arnd@...nel.org>
> > It's different from the exported namespace.
> > The function prefixes are needed due to C language, as we can't have
> > two functions named the same. The export OTOH is what used for linking
> > modules and if there is no need to have it exported globally, if, for
> > example, compiling in this one.
> >
> > So, can we move to the exported namespace at the same time?
>
> Maybe you can come up with a patch then?

Yes, why not.

> I have no idea
> which namespace to use here, seeing that there are already
> six differnet namespaces in use in drivers/platform/x86/intel/
> but none of them seem to be a good fit for this one.
>
> Are you asking to just define another namespace here?

Yes.

> How would I define what the rules about using this namespace
> are, and where are they documented?

Currently we use a common sense, like a pattern:
SUBSYSTEM_DRIVER
or so.

In this case INTEL_INT3472 is good enough as it's unique enough to not
collide with anything else in Intel's world (okay, I hope that we
learnt our mistakes in the past and won't issue same ACPI ID for
different devices).

-- 
With Best Regards,
Andy Shevchenko