On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> 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.
