On Tue, Apr 29, 2025 at 11:39:37AM +0800, Jason Wang wrote: > On Mon, Apr 21, 2025 at 11:46 AM Jason Wang <jasow...@redhat.com> wrote: > > > > On Mon, Apr 21, 2025 at 11:45 AM Jason Wang <jasow...@redhat.com> wrote: > > > > > > On Mon, Apr 21, 2025 at 10:45 AM Cindy Lu <l...@redhat.com> wrote: > > > > > > > > Introduce a new config knob `CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL`, > > > > to control the availability of the `VHOST_FORK_FROM_OWNER` ioctl. > > > > When CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL is set to n, the ioctl > > > > is disabled, and any attempt to use it will result in failure. > > > > > > I think we need to describe why the default value was chosen to be false. > > > > > > What's more, should we document the implications here? > > > > > > inherit_owner was set to false: this means "legacy" userspace may > > > > I meant "true" actually. > > MIchael, I'd expect inherit_owner to be false. Otherwise legacy > applications need to be modified in order to get the behaviour > recovered which is an impossible taks. > > Any idea on this? > > Thanks
At this point, as we changed the behaviour, we have two types of legacy applications - ones expecting inherit_owner false - ones expecting inherit_owner true Whatever we do, some of these will have to be changed. Given current kernel has it as true, and given it is a cleaner behaviour that will keep working when we disable CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL in 10 years, I think it's the better default. If you want to change it transparently, look for ways to distinguish between the two types. The application in question is qemu, is it not? I do not see how sticking an ioctl call into its source is such a big deal, if this is what we want to do. A bit of short term pain but we get clear maintainable semantics. -- MST
