Jarkko Sakkinen
Posts
5194Following
336Followers
520OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 11 minutes ago
can't wait for feedback for refreshed container objects once i get it finished :-) even if this ultimately results nack i think it is worth of trouble.
0
0
0
Jarkko Sakkinen
jarkko
The first time I got copilot feedback: https://github.com/himmelblau-idm/himmelblau/pull/1079
4/7 require additional feedback i.e., this pretty much explains why *what* is really the time consuming part, at least when aiming to production quality. In other words, you have unlimited ways to implement a functionality but no computation can cherry pick exactly right form from the unlimited options.
4/7 require additional feedback i.e., this pretty much explains why *what* is really the time consuming part, at least when aiming to production quality. In other words, you have unlimited ways to implement a functionality but no computation can cherry pick exactly right form from the unlimited options.
0
0
1
Jarkko Sakkinen
jarkko
I started rebasing and tuning dhowell's old container patches.
Right now I've bumped into use of "init_cred", which was made static in the recent past.
I guess I can address this by:
1. Removing static initialization of the field from struct container.
2. Adding a snippet of code to kernel initialization that assigns the same field dynamically using kernel_cred().
Is this the path I should take?
#linux #kernel
Right now I've bumped into use of "init_cred", which was made static in the recent past.
I guess I can address this by:
1. Removing static initialization of the field from struct container.
2. Adding a snippet of code to kernel initialization that assigns the same field dynamically using kernel_cred().
Is this the path I should take?
#linux #kernel
1
0
0
Jarkko Sakkinen
jarkko
0
1
1
Jarkko Sakkinen
jarkko
Edited yesterday
Created beginnings of TPM 2.0 emulator integrated directly to QEMU based on Infineon SLB9672. It requires compilation with optionally enabled Rust shenanigans.
Right now it processes only self-test, reading of capabilities and stuff like that but is bound and wired to qemu. I.e. can do "-tpmdev vtpm,id=tpm0".
Not out anytime soon but will be out in foreseeable future :-)
#qemu #tpm #emulator
Right now it processes only self-test, reading of capabilities and stuff like that but is bound and wired to qemu. I.e. can do "-tpmdev vtpm,id=tpm0".
Not out anytime soon but will be out in foreseeable future :-)
#qemu #tpm #emulator
3
4
10
Jarkko Sakkinen
jarkko
Edited 2 days ago
Speaking of swcam R&D benefits.
I talked about drones at LKML but you don't have to go that far in order to find useful places to improve QA using a software-define camera.
E.g., one could use it to improve tests of libcamera, pipewire and gstreamer ;-)
EDIT: and it could be utilized with WSL2 to provide video source for the VM environment.
I talked about drones at LKML but you don't have to go that far in order to find useful places to improve QA using a software-define camera.
E.g., one could use it to improve tests of libcamera, pipewire and gstreamer ;-)
EDIT: and it could be utilized with WSL2 to provide video source for the VM environment.
0
0
2
Jarkko Sakkinen
jarkko
Edited 4 days ago
Not posting this any time soon but now I think swcam has a decent uAPI where vidioc configuration is decoupled from producer of the stream. The producer provides a dataset of <pix_format, frame_rate> pairs that constraint the vidioc API upon creation and via SWCAM_IOC_WAIT gets the specs for the currently playing stream, always in the expected space of configurations.
The streaming pipeline itself has remained the same from the get go.
See:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/include/uapi/linux/swcam.h?h=vcam
Just wanted to put this to rebasable and complete state just in case (and I will continue to rebase the branch).
The streaming pipeline itself has remained the same from the get go.
See:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/include/uapi/linux/swcam.h?h=vcam
Just wanted to put this to rebasable and complete state just in case (and I will continue to rebase the branch).
1
0
0
Jarkko Sakkinen
jarkko
drafted my first ever himmelblau idm patch for dynamic user credential resolution :-) will take a while before any prs result.
0
0
0
Jarkko Sakkinen
jarkko
-MODULE_DESCRIPTION("V4L2 virtual camera driver");+MODULE_DESCRIPTION("V4L2 software camera driver");
a cosmetic change but describes better the scope and purpose. I.e. vcam -> swcam
a cosmetic change but describes better the scope and purpose. I.e. vcam -> swcam
0
0
0
Jarkko Sakkinen
jarkko
Edited 4 days ago
the next item in my backlog (i have a project to do something to every item in my personal backlog) are container objects. expected outcome is similar as for vcam initially i.e. "fuck no".
but since these are totally sidechannel things and nothing i take too personally i can still work on these topics if nothing else for my own entertainment :-) two years in a review cycle - i have zero problems with that.
i do give up on patch sets even if i've made myself a fool promoting them every single time when objective facts fight against them that i can understand with my limited brain capacity. up until that i go against the wind :-)
but since these are totally sidechannel things and nothing i take too personally i can still work on these topics if nothing else for my own entertainment :-) two years in a review cycle - i have zero problems with that.
i do give up on patch sets even if i've made myself a fool promoting them every single time when objective facts fight against them that i can understand with my limited brain capacity. up until that i go against the wind :-)
0
0
1
Jarkko Sakkinen
jarkko
It is good to remark libcamerify from libcamera-tools is LD_PRELOAD based solution for "virtual camera", not ubiquitos solution really. It is also across the board much more stressing and higher latency solution for system than a well-designed loopback device.
0
0
0
Jarkko Sakkinen
jarkko
1
0
2
Jarkko Sakkinen
jarkko
For the v2 I think I have sane way to constrain the state i.e., in VCAM_IOC_CREATE:
__u32 nr_states;
__u32 states;
Each state (32 bytes per state) specifies configuration with pixel format, geometry, stride etc.
Obviously this means some redundancy perhaps because one has to address e.g. same width and height in different configurations but I think in the end this database approach is the most robust pick.
__u32 nr_states;
__u32 states;
Each state (32 bytes per state) specifies configuration with pixel format, geometry, stride etc.
Obviously this means some redundancy perhaps because one has to address e.g. same width and height in different configurations but I think in the end this database approach is the most robust pick.
1
0
0
Jarkko Sakkinen
jarkko
Edited 5 days ago
Test code I have cleaned up relocated:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/vcam-test.git
From this i spin off at least some kind of initial kselftest.
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/vcam-test.git
From this i spin off at least some kind of initial kselftest.
1
0
0
Jarkko Sakkinen
jarkko
Edited 6 days ago
Despite the feedback does not look very accepting, continuing with vcam makes common sense to me enough that I continue improving and rebasing it.
In order to lift it up from RFC phase at least property negotiation needs some rework, there's some compliance suites for V4L2 to try out and of course some test code needs to be supplemented.
Up side with resistance is at least that it is antidote for a loose send-finger :-) I'll focus on making each iteration considerably better than N - 1.
In order to lift it up from RFC phase at least property negotiation needs some rework, there's some compliance suites for V4L2 to try out and of course some test code needs to be supplemented.
Up side with resistance is at least that it is antidote for a loose send-finger :-) I'll focus on making each iteration considerably better than N - 1.
1
0
0
Jarkko Sakkinen
jarkko
v4l2loopback has highly scattered but at the same time wide base. It even includes stuff like scientific research. Here's one recent'ish example: https://dl.acm.org/doi/epdf/10.1145/3664647.3681007. This also implies that it is a tainted driver likely deployed to multiple critical organizations and environments.
This type of feature is also quite robust tool for many uses where emulation is required but we still need sufficient figures for latency and throughput. It could be applied e.g., to drone platform testing where vision can be mocked with virtual devices providing simulated environment or pre-recorded environment (for training AI).
It is also good to keep in mind not every single piece of legacy software can be magically turned into PipeWire clients, and neither it is a great fit all possible deployments of Linux.
This type of feature is also quite robust tool for many uses where emulation is required but we still need sufficient figures for latency and throughput. It could be applied e.g., to drone platform testing where vision can be mocked with virtual devices providing simulated environment or pre-recorded environment (for training AI).
It is also good to keep in mind not every single piece of legacy software can be magically turned into PipeWire clients, and neither it is a great fit all possible deployments of Linux.
0
0
1
Jarkko Sakkinen
jarkko
OK, there's 6.19-rc8. Has not happened for a while, or at least don't recall
0
0
0
Jarkko Sakkinen
jarkko
IMHO vcam is a bit like ntsync. In other words, it is somewhat use case optimized but the use case is just relevant enough to make it sense to have the feature in the mainline kernel.
0
0
0
Jarkko Sakkinen
jarkko
I didn't really know all the time what I was doing but I at least the choice of tying the pole providing the service tightly to dma-buf was a right design choice :-) This has been somewhat experimental project.
0
0
0