Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support

[Dan Williams <dan.j.williams@intel.com>]

On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
[..]
> > If it simplifies the kernel implementation to assume single
> > kernel-initiator then I think that's more than enough reason to block
> > out userspace, and/or provide userspace a method to get into the
> > kernel's queue for service.
>
> This last suggestion makes sense to me. Let's provide a 'right' way
> to access the DOE from user space. I like the idea if it being possible
> to run CXL compliance tests from userspace whilst the driver is loaded.

Ah, and I like your observation that once the kernel provides a
"right" way to access DOE then userspace direct-access of DOE is
indeed a "you get to keep the pieces" event like any other unwanted
userspace config-write.

> Bjorn, given this would be a generic PCI thing, any preference for what
> this interface might look like?   /dev/pcidoe[xxxxxx].i with ioctls similar
> to those for the BAR based CXL mailboxes?

(warning, anti-ioctl bias incoming...)

Hmm, DOE has an enumeration capability, could the DOE driver use a
scheme to have a sysfs bin_attr per discovered object type? This would
make it simliar to the pci-vpd sysfs interface.

Then the kernel could cache objects like CDAT that don't change
outside of some invalidation event.