@Conan_Kudo

I don't know and I knowingly do not check the previous submission albeit I know it exists. I check that only when I plan to send this. It is a risk because it might dilate my creative thinking :-) I don't care if the first submission does not end up anywhere as I don't have any rush for this, i.e. can do as many iterations as required. I'm also pretty seasoned and patent when it comes to LKML ;-) I.e. that part is least of my worries, or I don't give a fuck to say it straight :-)

Please take this with a grain of salt how the code is *right now* (i.e. not yet ready for review) as I've had to take a break from this (had not free bandwidth).

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=v4l2-loopback&id=4a4a2cfa6724dc546e1ab4d56e8a15461512e7ce

I also have a matching test program, which tracks 1:1 the ioctl changes:

https://codeberg.org/jarkko/v4l2-loopback-test/

The commit on top is my staging area not something you see in the final patch set. The test program helps me to make sure that I don't catastrophically break anything.

I'll basically do for RFC (not final proposal):

1. NOT clean up the code because of cleaning up :-) Changing "presumable messy" is a risk. Any clean ups are only a side-effects of doing something actually useful. I also highly respect others peoples work in open source so I always have crystal clear reason for any possible delta.
2. Refactor ioctl signatures and structures to be ABI agnostic.
3. open(/dev/v4l2-loopback): create a new loopback driver.
4. V4L2LOOPBACK_CTL_ADD: add a new capture/output device to the loopback driver.
5. close(/dev/v4l2-loopback): tear down the driver (and obviously also devices it has created).
6. Define a sane locking model for the internals. I'm not 100% if it works but at least it does not have good coherence. It should be dead obvious how locks work in any driver and should documented in the header (which I'll do).

For cover letter I'll put an option to rewrite with Rust since it is hardware agnostic (and thus that would make sense in new driver). The first RFC version is in C in order to draw a clear path from OTT, to in-kernel C and finally to Rust.

I don't care how many iterations it takes as it is just a hobby sudoku for me.

Phew. Well this was good because 3 weeks gone since last lookup. I'm happy that I have a test program since especially after changing how devices are created and adding necessary anonymous inode shenanigans you need to be able to test those iterations as you go.