linux-kernel - Re: [RFC PATCH 2/9] cxl/acpi: add OSC support

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: <CAPcyv4ixeG9Puoob5yKRe3UDgehzJKPA32aiurZi-55-G-U17A@mail.gmail.com>
Date:   Wed, 18 Nov 2020 09:58:11 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Ben Widawsky <ben.widawsky@...el.com>,
        linux-cxl@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Ira Weiny <ira.weiny@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        "Kelley, Sean V" <sean.v.kelley@...el.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [RFC PATCH 2/9] cxl/acpi: add OSC support

On Wed, Nov 18, 2020 at 4:26 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Tue, Nov 17, 2020 at 12:26 AM Dan Williams <dan.j.williams@...el.com> wrote:
> >
> > On Mon, Nov 16, 2020 at 10:00 AM Jonathan Cameron
> > <Jonathan.Cameron@...wei.com> wrote:
> > >
> > > On Tue, 10 Nov 2020 21:43:49 -0800
> > > Ben Widawsky <ben.widawsky@...el.com> wrote:
> > >
> > > > From: Vishal Verma <vishal.l.verma@...el.com>
> > > >
> > > > Add support to advertise OS capabilities, and request OS control for CXL
> > > > features using the ACPI _OSC mechanism. Advertise support for all
> > > > possible CXL features, and attempt to request control too for all
> > > > possible features.
> > > >
> > > > Based on a patch by Sean Kelley.
> > > >
> > > > Signed-off-by: Vishal Verma <vishal.l.verma@...el.com>
> > > > Signed-off-by: Ben Widawsky <ben.widawsky@...el.com>
> > >
> > > I guess unsurprisingly a lot of this is cut and paste from PCIe
> > > so can we share some of the code?
> > >
> >
> > I do not see a refactoring effort for these bit being all that
> > fruitful.
>
> Well, that depends on how much code duplication could be avoided this way.
>
> > The backport pressure for this driver stack I expect will be
> > higher than most, so I'm sensitive to avoiding unnecessary core
> > entanglements.
>
> If two pieces of code are based on the same underlying common code, it
> is immediately clear to the reader how similar to each other they are.
> Otherwise, they need to be carefully compared with each other to find
> out what the differences are and whether or not they are arbitrary or
> vitally important.  That is essential both from the revirem
> perspective today and to anyone wanting to understand the given code
> in the future (possibly in order to modify it without breaking it).
> It outweighs the convenience by far IMV, with all due respect.
>
> Recall how much effort it took to combine x86 with x86_64 and why it
> turned out to be necessary to do that work, for one example.

I agree with above, but the degree of potential code sharing and
refactoring for CXL is nowhere near approaching the x86_64 situation.
There's also the counter example in ext3 and ext4 where a split is
maintained for good reason. All I'm saying is that let's judge patches
and not theory when it comes to refactoring CXL, my expectation is
that those opportunities will be few and far between. CXL is a
superset of PCIE functionality so it should not put much pressure on
common core PCIE code to change vs incremental CXL extensions.