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]
Date:   Tue, 25 Jun 2019 09:02:46 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jonathan Cameron <jonathan.cameron@...wei.com>
Cc:     X86 ML <x86@...nel.org>, Len Brown <lenb@...nel.org>,
        Keith Busch <keith.busch@...el.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Vishal L Verma <vishal.l.verma@...el.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 01/10] acpi/numa: Establish a new drivers/acpi/numa/ directory

On Tue, Jun 25, 2019 at 8:01 AM Jonathan Cameron
<jonathan.cameron@...wei.com> wrote:
>
> On Mon, 24 Jun 2019 11:19:32 -0700
> Dan Williams <dan.j.williams@...el.com> wrote:
>
> > Currently hmat.c lives under an "hmat" directory which does not enhance
> > the description of the file. The initial motivation for giving hmat.c
> > its own directory was to delineate it as mm functionality in contrast to
> > ACPI device driver functionality.
> >
> > As ACPI continues to play an increasing role in conveying
> > memory location and performance topology information to the OS take the
> > opportunity to co-locate these NUMA relevant tables in a combined
> > directory.
> >
> > numa.c is renamed to srat.c and moved to drivers/acpi/numa/ along with
> > hmat.c.
>
> Hi Dan,
>
> srat.c now includes processing for the slit table which is a bit odd.
>
> Now we could split this up in to a top level numa.c and then
> srat.c, slit.c and hmat.c....
>
> Does feel rather silly though.  Perhaps better to just leave it as
> numa.c?

The srat and slit tables go hand in hand, I'm not too bothered by the
fact that the slit table does not get top billing with its own source
file name.

The "numa" term is already in the path name, and calling numa.c leaves
out hmat details which are also "numa".

> I don't really feel strongly about this though.

Understood, I just did not see the justification for HMAT being off in
its own directory when it is a direct extension of the existing
ACPI_NUMA functionality, the other renames were my best effort to
rationalize the code organization.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ