On Fri, Jan 30, 2026 at 3:17 AM Jason Wang <[email protected]> wrote: > > On Thu, Jan 29, 2026 at 4:08 PM Eugenio Perez Martin > <[email protected]> wrote: > > > > On Thu, Jan 29, 2026 at 3:00 AM Jason Wang <[email protected]> wrote: > > > > > > On Wed, Jan 28, 2026 at 8:45 PM Eugenio Pérez <[email protected]> wrote: > > > > > > > > Introduce the definition for VDUSE API V2. This version serves as a > > > > gateway for feature negotiation. > > > > > > > > The kernel uses this version to determine if the userspace device > > > > supports feature flags. Devices that do not explicitly negotiate API V2 > > > > will be blocked from querying available VDUSE features, ensuring > > > > backward compatibility. > > > > > > > > The next patches implement the new feature incrementally, only enabling > > > > the VDUSE device to set the V2 API version by the end of the series. > > > > > > > > Signed-off-by: Eugenio Pérez <[email protected]> > > > > --- > > > > include/uapi/linux/vduse.h | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h > > > > index 68b4287f9fac..dea89ed281a7 100644 > > > > --- a/include/uapi/linux/vduse.h > > > > +++ b/include/uapi/linux/vduse.h > > > > @@ -14,6 +14,10 @@ > > > > > > > > #define VDUSE_API_VERSION_1 1 > > > > > > > > +/* Features support */ > > > > + > > > > +#define VDUSE_API_VERSION_2 2 > > > > > > If we can catch the next release cycle, I would perfer not bumping > > > VDUSE version twice in the same release. > > > > > > > Following the number of versions that ASID required I don't expect > > this one to be ready for the next release cycle :). > > Then it's probably fine. > > > > > But if you ack the patches related with the vduse features handling, > > MST is ok with that, and we're still in time to reach linux-next and > > the next Linux, I can prepare a series where I add the features bits > > to V1 API. Then, all ASID and VQ_ENABLE will be handled by feature > > bits. Would that work for both of you? > > Maybe you can start with V1 and if we can't catch this release, a > respin will be needed anyhow. >
I'm fine with that if you ask it, but if it gets merged (unlikely) we'll have a few commits with V1 that supports the VDUSE_GET_FEATURES and others that do not.
