@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 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 ... once you get the grip,

@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

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.

"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 ;-)

@garrett The conclusion that Grub must die is anyway pretty obvious one.

Grub is what it is because it was "UEFI" before UEFI.

@garrett I use systemd-boot e.g. in my ad-hoc VM's and stuff like that but for my host desktop I don't care how it boots, as long as it boots (unless I'm paid to figure out, not saying it wouldn't be fun and interesting).

In that sense +1 for systemd-boot. I don't mind as long my computer boots.

@garrett Fedora uses it as the default? :-) At least my Fedora 41 installation uses Grub.

Ketä Iltalehdessä on oikein töissä!? Esikoululaisia?

(Silti salaa naureskelen...)

IL: "Nainen pieraisi puhelimeen"
IL: "Outokumpulaisesta syväreiästä tehtiin haiseva löytö"

@CedricLevasseur believe it or not: im on your side in this story even if you disliked me because of what i said 🙂 that is all i care

@CedricLevasseur i personally would never hire AI to make software. It’s based on facts and over 20 decades of experience in this business. It would destroy creative distruption and would not bring edge in competition. I also read books only written by humans because im a human. AI is a cost. Person is an investment.

@CedricLevasseur I dont believe it does because most of time is figuring out what not how. It’s over rated

@CedricLevasseur @AuthorJMac @danslerush i use ai so rarely even in the use case i described that i even dont know what IA is. No interest on topic to ”do the research” either. I thought it was a typo

@CedricLevasseur @danslerush @AuthorJMac Dude, you should too.

@guenther lol very true, apologies :-)

@CedricLevasseur @AuthorJMac @danslerush E.g. software engineering: at most 10% is about the source code. Rest is human interaction and expectations, even in something as low-level as drivers and stuff like that.

I've always said that I would be as effective in statistics with Windows Notepad doing Linux drivers as I am on Linux system with vim even tho that will decrease my code productivity by factors. You pick the tools you like, the productivity and creativity are not affected. I personally love slow.

@CedricLevasseur @danslerush @AuthorJMac I have one useful application for AI that is also my main use case:

1. I have a Github issue with 100'ish comments with some relevant, some random nagging or generally irrelevant shit, links and shit.
2. I ask AI to aggregate the data, not add or remove new information but just give me report what is there so that I don't have to bother scrolling all the comments.

I don't get much of AI creating anything "new" for me because I do actually new stuff. It costs me time because even if AI generates me something I would need to go it through and I end up dissapointing result that I need to rewrite myself.

I've also empirically tested these theories because I don't believe in belief systems.

E.g. a platform bug makes it propose solutions that don't work because there's too many parameters that are not the source code per se like the environment it runs, and how people might want it to fly. If I give more feedback to the AI, it always ends up eventually proposing the same dysfunctional solution I started with.

But my first example: it s actually useful. I also know a startup that did a system for customer service, which does not replace it but instead quickly provides context information for the call service person, which makes the work less stressful and customers get highest possible result. Nobody likes to talk AI on phone.

Whenever there is a new tech it will take all our jobs but eventually it settles and integrates. E.g. if AI really did that it would start feeding back itself with its own data because everything would be generated by AI. Even some studies have started to shown evidence that this can cause a feedback alzheimer kind of condition for the LLM.

I did my homework on this. Thus, not worried.

:-)

Got some books. The bottom one: I'm familiar with it just did not have my personal copy. Made sense to order it now as I pre-ordered Randal Hyde's (aka a living legend) new ARM edition: https://nostarch.com/art-arm-assembly-volume-1

@cos oh thanks!