"keep calm and hack linux"

My job situation back to more Linux oriented work, which should allow me to have space to work on also on my unfinished patch sets i.e.

1. Continue with v4l2-loopback (according to Git last time touched 2025-19-01)
2. TPM2 asymetric keys (2024-11-18).

Nothing is fully closed yet but having a meeting for one decent opportunity tomorrow that I will consider. Thus, also open for queries since you never know until ink is on the paper of course ;-)

@jarkko What do you plan to do differently that will allow v4l2-loopback to make it into the kernel this time?

@Conan_Kudo haha, I asked the same question before. The gist was (paraphrasing): make it better by following the actual v4l2 device model, make the code easier to read.
Do I remember correctly @jarkko ?

@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.

@Conan_Kudo Bookmarked as source material for the cover letter. But yeah "eventual Rust driver" is my plan with first steps in C. Rewriting a driver takes me a day once I have the design in my head so it is only fun then...

@Conan_Kudo ... once you get the grip,

@Conan_Kudo I promised to Steve Klabnik to test out DMA Rust patch set when he was complaining about that in Bluesky.

The selfish goal in that is that while I do this, that pushes me to rework my BR environment to be "Rust enabled" and testing some actual Rust kernel code probably helps me to draw the mental picture how to make this work in Rust.

... and obviously keeping that promise because if I say something, I usually also execute it (with some delays ofc like in this case) :-)

@Conan_Kudo Hmm... So I have guess what has happened in "meta-level" with previous submissions: if you don't have a smoke test you hang yourself to the existing user space toolchain and the API is really the part here that sucks the most and needs a lot of rework. It's racy and bad. So what I do in meta-level here correctly that I took pause writing kernel code, and made a trivial smoke test program. That's why I believe that I will eventually deliver.

@Conan_Kudo I should learn to not write a spam thread but yeah for better or worse this is how i aim.

@jarkko That sounds great. Yeah, you've addressed most of it. There's also a foundational issue that occurred way back when that the v4l people consider it a loophole for proprietary camera drivers. I suspect this might not be an issue anymore now that MIPI allows this anyway and people are *currently* abusing it for proprietary camera drivers *today*.

@Conan_Kudo sorry for responding with million messages tho :-) sometimes can't help myself...

@Conan_Kudo Personally I don't believe that loophole is commercially viable at least not in volumes (maybe for some niche product) but I leave that burden to LKML discussion :-)

PS. I meant to like your encouraging comment but for some reason Mastodon sometimes does like me to like :-) Anyway thanks!

@jarkko When you get around to sending the patch set, feel free to Cc me for it. I'm happy to look over and review it. 😃

@Conan_Kudo sure and it will happen :-)

@Conan_Kudo Also I think it was good to think it through myself rather read the feedback. If I had started to read the feedback I would have run away at instant. Now I've modeled the problem areas myself and have better clarity. Feedback can be also a huge distraction factor when u are starting :-) Not same as ignoring it but one way to cause unnecessary paralysis at starting point.