I'll do some initial clean ups to get the worst incompatible mess away and then can open the tree (in some days) if that makes sense to you?

https://codeberg.org/jarkko/linux-v4l2-loopback/src/branch/v4l2-loopback

So there's a tree and I think this DoD for the issue. This branch baseline's to v6.13 and is meant to prepare RFC version of the patch set. Many of your fixes probably makes sense but you will have the trouble of creating Codeberg account :-)

I kept the starting point version still API compatible but not that it does not pre-create devices. Tools still work as of now. So I guess we can close this as now there is a platform for discussion?

Codeberg is not necessarily that much ideology based choice here. It's more like a platform with less random noise than Github.

So the process is simple really:

1. Pile patches on top of the current branch up until it is ready for RFC.
2. Squash the patches into patch set and send it to LKML.
3. Create a new branch branch for v2 and repeat.

It's a long road for this kind of driver but this is the process to make it happen. I'll update the baseline once per patch set version. Also tests need to be refined once API breakages happen etc. As said I have this one really trivial to refactor: https://codeberg.org/jarkko/v4l2-loopback-test/

https://codeberg.org/jarkko/linux-v4l2-loopback/wiki/Home

So yeah what I'll do is that I'll continue what I was doing but am open for pull requests, and as said some of the fixes probably make still sense that you did for this repository. I'll worry more about the device model than internals but before it makes to change API, the internals need to be cleaned up piece by piece.

First good step towards the new API would be to replace 'announce_all_caps` in config with capabilities and define output/capture (or both) at creation time. That's one step nearer to more mainline compatible API. That will also simplify the use of existing state variables.

... parameters are not size-encoded (e.g. __u32) in the ioctl API, which is immediate reject. So that alone is a huge issue.

ABI compatibility is not really an issue as I suspect very few applications are using the module's ioctls other than v4l2loopback-ctl.

Anything that goes to upstream driver's life-cycle should be tied into fd's life-cycle. I.e. ioctl gives you a file descriptor and that keeps video device alive as long as the device is needed. Thus, there will be zero pre-created devices.

It's the same idea as with KVM, tpm_vtpm_proxy and many other subsystems. This OOT API lacks:

1. Clear life-cycle model.
2. Clear security model (i.e. we cannot define who can act as video driver but with ioctl returning fd we can).

It will never be accepted like it is trust me. This device pre-creation is hack or workaround around broken device life-cycle model. That is the main gist that I'm working on.

Makes sense - I didn't expect the module parameters that 'create' device nodes to make sense in-tree (given my very limited knowledge).

@umlaeute is the authority when it comes to this module; I only jumped in recently to resolve a few bugs. Hopefully they can help more than I when it comes to API and how to design the module's IOCTLs.

Yeah so generally user drivers should only create device if kernel also knows when to destroy them. I.e. be invoking the ioctl you create a communications end point for an user driver. Only clients use /dev/videoX. So what I'm introducing is this asymmetry, which is pretty much the design pattern in kernel that "everything uses". File descriptors lock-in drivers life cycle to the process life-cycle, thus creating sort of like "micro-kernel" type of infrastructure.

So how it should work would be that ioctl gives you communications end to talk to the client, which is just a file descriptors:

1. Driver opens /dev/video_loopback
2. Receives fd, video device is created to the clients.
3. When the drivers closes and fd closes, also device is eventually deleted.

Obviously there's a situation when clients have the device still open. In this case kernel will return -EIO or similar until all open files to that device have been closed.

Right and capabilities: they should be provided when the video device node is created and be static in that way. Now this depends on stream state and open files (as I described in the state variables earlier).

Anyway, I think I explained my plan and repository is available for providing fixes etc. :-)

So for me personally this issue now reached definition of done. I'm no longer working on the topic isolated and am open for PR's to move things forward. Right, and I did read your descriptions and they are around the ballpark what I think it should go. Just is beyond the scope discuss here every possible detail.

Everything in kernel is based on this very same pattern when user space provides a service. See for example: https://lwn.net/Articles/658511/

@stephematician sorry I did not know what you mean by pairs but yeah, there is owner fd and that pairs with clients, yes.

I think you got it overall.

Also I update the kernel tree slice by slice and if some change does not make sense there is always git revert command to retract. So if you want you are welcome to contribute (as anyone else). The important thing in this tree is to keep the commits focused because I suspect some missteps might be taken.

It's super rare to see that variant, thus asking.

I didn't write that part; at a guess - maybe they wanted to avoid the timer callbacks while in check_timer() ... but they could have added spin_lock within the timer callbacks and achieved the same result (unless I've missed something).

There is also dev->lock taken with just regular spin_lock() in the write callback. OK, not a high priority problem to sort out... Thanks for input.

Yeah. I'm not sure why it doesn't just use locked IOCTLs - e.g. via video_device->lock, but maybe that's not common - or considered overkill - in V4L2 drivers?

Yeah not a high priority concern :-)

I think ... if one timer callback has the lock, and then it gets interrupted by another timer callback, that would be bad. Perhaps that's why the used spin_lock_bh.

mostly because it predates any meaningful way to query the available formats

@umlaeute Thanks, I'm just super careful with any removals, much appreciated.

I think I should include you to as co-developed-by to some time in (not yet sure how distant) future patch set. Or you one of the authors in the first commit of my pile (to be squashed)?

https://codeberg.org/jarkko/linux-v4l2-loopback/commits/branch/v4l2-loopback

It's based on this work, and yeah credit definitely deserved. And my gist with this is to strip of legacy clutter, refine mainline-feasible uapi but not destroy anything for the sake of it.

You can see the list of co-developed-by's from "media: v4l2-loopback" commit.

I.e. I'm not here to steal or take credit of anyone's good work. I'm just here to wrap it up to a sane device model :-) It all builds on top of this awesome work in the end of the day.

I'm only a bug fixer for v4l2loopback at this stage. The developer that deserves credit is @umlaeute. Also if I'm not needed - I've got other projects I can focus on, so don't worry about me if you work better alone!

OK, good. Even when I get RFC out it will take probably few review rounds. I.e. this driver is needed for a long time still.

If you're keen to replace the way buffers and streams are handled with the videobuf2 framework and split devices; then I'm happy to sit and wait until you've finished then port them to the out-of-tree module (if there's appetite for it).

Yes, I'm looking into that but most likely go with the API part first. It's not actually that hard. I really need to just add a new role to the opener to get first PoC.

BTW, just a tidbit but I there's one trivial thing that could be done also to the OOT driver (probably): there's no need to pick the device from idr, you could just as well assign directly to video_drvdata.

As per instructions I took yours and added them to the wiki for reference: https://codeberg.org/jarkko/linux-v4l2-loopback/wiki/Home

OK, good, since you asked for it I explained what I'm doing that's all :-)