On 2/5/25 20:05, Dan Williams wrote:

Dan Williams wrote:
[..]

quoted

I think there is a benefit from a driver being able to do someting like:

struct my_cxl_accelerator_context {
     ...
     struct cxl_dev_state cxlds;
     ...
};

Even if the rule is that direct consumption of 'struct cxl_dev_state'
outside of the cxl core is unwanted.

C does not make this easy, so it is either make the definition of
'struct cxl_dev_state' public to CXL accelerator drivers so that they
know the size, or add an allocation API that takes in the extra size
that accelerator needs to allocate the core CXL context.

Jason has a novel approach to this problem of defining an allocation
interface that lets the caller register a caller provided data structure
that wraps a core internal object. Have a look at fwctl_alloc_device()
for inspiration:

http://lore.kernel.org/1-v3-960f17f90f17+516-fwctl_jgg@nvidia.com (local)

I'm not sure what you mean here, and I just gave a quick look to that 
reference, but in my opinion, it is quite different userspace triggering 
some sort of allocation based on some sysfs files giving the relevant 
information than a kernel driver using an internal kernel API.


Anyway, if you have look at v10, I have modified the accel driver 
allocation for state using the memdev state instead which makes more 
sense to me. I did use that from your original patch, but it makes 
things complicated and a Type2 is a memdev after all. The code is 
cleaner and simpler now.