* Re: Supporting out of tree custom vhost target modules [not found] <CA+Lg+WFYqXdNUJ2ZQ0=TY58T+Pyay4ONT=8z3LASQXSqN3A0VA@mail.gmail.com> @ 2025-04-23 10:01 ` Michael S. Tsirkin 2025-04-23 10:48 ` David George 0 siblings, 1 reply; 4+ messages in thread From: Michael S. Tsirkin @ 2025-04-23 10:01 UTC (permalink / raw) To: David George; +Cc: netdev, jasowang 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Supporting out of tree custom vhost target modules 2025-04-23 10:01 ` Supporting out of tree custom vhost target modules Michael S. Tsirkin @ 2025-04-23 10:48 ` David George 2025-04-23 12:34 ` Andrew Lunn 2025-04-23 12:34 ` Michael S. Tsirkin 0 siblings, 2 replies; 4+ messages in thread From: David George @ 2025-04-23 10:48 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: netdev, jasowang 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Supporting out of tree custom vhost target modules 2025-04-23 10:48 ` David George @ 2025-04-23 12:34 ` Andrew Lunn 2025-04-23 12:34 ` Michael S. Tsirkin 1 sibling, 0 replies; 4+ messages in thread From: Andrew Lunn @ 2025-04-23 12:34 UTC (permalink / raw) To: David George; +Cc: Michael S. Tsirkin, netdev, jasowang 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Supporting out of tree custom vhost target modules 2025-04-23 10:48 ` David George 2025-04-23 12:34 ` Andrew Lunn @ 2025-04-23 12:34 ` Michael S. Tsirkin 1 sibling, 0 replies; 4+ messages in thread From: Michael S. Tsirkin @ 2025-04-23 12:34 UTC (permalink / raw) To: David George; +Cc: netdev, jasowang 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-04-23 12:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CA+Lg+WFYqXdNUJ2ZQ0=TY58T+Pyay4ONT=8z3LASQXSqN3A0VA@mail.gmail.com>
2025-04-23 10:01 ` Supporting out of tree custom vhost target modules Michael S. Tsirkin
2025-04-23 10:48 ` David George
2025-04-23 12:34 ` Andrew Lunn
2025-04-23 12:34 ` Michael S. Tsirkin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).