[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <662d263dd17c7_b6e0294ab@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date: Sat, 27 Apr 2024 09:22:21 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Greg KH <gregkh@...uxfoundation.org>, Harold Johnson
<harold.johnson@...adcom.com>
CC: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Dan Williams
<dan.j.williams@...el.com>, <linux-cxl@...r.kernel.org>, Sreenivas Bagalkote
<sreenivas.bagalkote@...adcom.com>, Brett Henning
<brett.henning@...adcom.com>, Sumanesh Samanta
<sumanesh.samanta@...adcom.com>, <linux-kernel@...r.kernel.org>, "Davidlohr
Bueso" <dave@...olabs.net>, Dave Jiang <dave.jiang@...el.com>, "Alison
Schofield" <alison.schofield@...el.com>, Vishal Verma
<vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>,
<linuxarm@...wei.com>, <linux-api@...r.kernel.org>, Lorenzo Pieralisi
<lpieralisi@...nel.org>, "Natu, Mahesh" <mahesh.natu@...el.com>
Subject: Re: RFC: Restricting userspace interfaces for CXL fabric management
Greg KH wrote:
[..]
> So while innovating at the hardware level is fine, follow the ways that
> everyone has done this for other specification types (USB, PCI, etc.)
> and just allow vendor drivers to provide the information. Don't do this
> in crazy userspace drivers which will circumvent the whole reason we
> have standard kernel/user apis in the first place for these types of
> things.
Right, standard kernel/user apis is the requirement.
The suggestion of opaque vendor passthrough tunnels, and every vendor
ships their custom tool to do what should be common flows, is where this
discussion went off the rails.
Powered by blists - more mailing lists