[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210201182400.GK197521@fedora>
Date: Mon, 1 Feb 2021 13:24:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Ben Widawsky <ben.widawsky@...el.com>
Cc: linux-cxl@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-nvdimm@...ts.01.org,
linux-pci@...r.kernel.org, Bjorn Helgaas <helgaas@...nel.org>,
Chris Browy <cbrowy@...ry-design.com>,
Christoph Hellwig <hch@...radead.org>,
Dan Williams <dan.j.williams@...el.com>,
Ira Weiny <ira.weiny@...el.com>,
Jon Masters <jcm@...masters.org>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
Randy Dunlap <rdunlap@...radead.org>,
Vishal Verma <vishal.l.verma@...el.com>,
daniel.lll@...baba-inc.com,
"John Groves (jgroves)" <jgroves@...ron.com>,
"Kelley, Sean V" <sean.v.kelley@...el.com>
Subject: Re: [PATCH 09/14] cxl/mem: Add a "RAW" send command
On Fri, Jan 29, 2021 at 04:24:33PM -0800, Ben Widawsky wrote:
> The CXL memory device send interface will have a number of supported
> commands. The raw command is not such a command. Raw commands allow
> userspace to send a specified opcode to the underlying hardware and
> bypass all driver checks on the command. This is useful for a couple of
> usecases, mainly:
> 1. Undocumented vendor specific hardware commands
> 2. Prototyping new hardware commands not yet supported by the driver
This sounds like a recipe for ..
In case you really really want this may I recommend you do two things:
- Wrap this whole thing with #ifdef
CONFIG_CXL_DEBUG_THIS_WILL_DESTROY_YOUR_LIFE
(or something equivalant to make it clear this should never be
enabled in production kernels).
- Add a nice big fat printk in dmesg telling the user that they
are creating a unstable parallel universe that will lead to their
blood pressure going sky-high, or perhaps something more professional
sounding.
- Rethink this. Do you really really want to encourage vendors
to use this raw API instead of them using the proper APIs?
>
> While this all sounds very powerful it comes with a couple of caveats:
> 1. Bug reports using raw commands will not get the same level of
> attention as bug reports using supported commands (via taint).
> 2. Supported commands will be rejected by the RAW command.
>
> With this comes new debugfs knob to allow full access to your toes with
> your weapon of choice.
Problem is that debugfs is no longer "debug" but is enabled in
production kernel.
Powered by blists - more mailing lists