Re: Supporting out of tree custom vhost target modules

Re: Supporting out of tree custom vhost target modules

[Michael S. Tsirkin]

On Wed, Apr 23, 2025 at 11:47:49AM +0200, David George wrote:
> Hello all
> 
> I am in the process of writing an out of tree kernel module that does a very
> similar job to vhost_net.  The problem is that plain tap devices aren't quite
> going to cover what I want to do (1:N device mapping and various exotic
> offloads).
> 
> The approach I am taking at the moment is to tweak vhost/net.c to suit my needs
> and operate it as an out of tree module. The problem with this approach is the
> "vhost.h" is not in include/ so won't be usable without the whole source tree
> to compile against.
> 
> Is promoting vhost.h from drivers/vhost to include/xyz/ something that could be
> considered?
> 
> Alternatively, what I want to do could perhaps be done through an API to
> register a custom socket associated with a custom misc dev within vhost_net,
> but that is a lot more invasive.
> 
> Thanks,
> David George

See no good reason for that, that header is there so modules outside
of vhost don't use it by mistake.

Re: Supporting out of tree custom vhost target modules

[David George]

Thanks for the response Michael.

And apologies for the earlier html content.

> See no good reason for that, that header is there so modules outside
> of vhost don't use it by mistake.

I suppose what I would really be suggesting is adding the possibility
of a driver outside of vhost/ being able to include _something_,
enough for it to implement its own vhost target. If you don't see this
as being useful outside of my use, or my case too narrow, then I
suppose there probably is no good reason.

Alternatively, what did you think of the suggestion of introducing a
mechanism of a custom backend for vhost_net? In principal it could
make the existing mechanism a little neater perhaps?

David

Re: Supporting out of tree custom vhost target modules

[Andrew Lunn]

On Wed, Apr 23, 2025 at 12:48:59PM +0200, David George wrote:
> Thanks for the response Michael.
> 
> And apologies for the earlier html content.
> 
> > See no good reason for that, that header is there so modules outside
> > of vhost don't use it by mistake.
> 
> I suppose what I would really be suggesting is adding the possibility
> of a driver outside of vhost/ being able to include _something_,
> enough for it to implement its own vhost target.

Putting the header somewhere private is a design feature to stop the
internal API from being abused.

Now, you are creating an out of tree module, you can abuse anything
how you want, nobody cares. You can simply say your driver needs to be
built against the kernel sources, not just the includes, and you can
extend the include path to go deep into the tree.

	Andrew

Re: Supporting out of tree custom vhost target modules

[Michael S. Tsirkin]

On Wed, Apr 23, 2025 at 12:48:59PM +0200, David George wrote:
> Thanks for the response Michael.
> 
> And apologies for the earlier html content.
> 
> > See no good reason for that, that header is there so modules outside
> > of vhost don't use it by mistake.
> 
> I suppose what I would really be suggesting is adding the possibility
> of a driver outside of vhost/ being able to include _something_,
> enough for it to implement its own vhost target. If you don't see this
> as being useful outside of my use, or my case too narrow, then I
> suppose there probably is no good reason.
> 
> Alternatively, what did you think of the suggestion of introducing a
> mechanism of a custom backend for vhost_net? In principal it could
> make the existing mechanism a little neater perhaps?
> 
> David

An out of tree module isn't a usecase I care about.
If you make the code neater, I'll be happy to accept the patch.


-- 
MST