Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

Hello everyone, Hoshino Lina here! I'm a developer VTuber!
I also help run VT Social!

EN/日本語｜she/her｜🎨 #HoshinoLinArt｜My gf: Cyan Nyan 星乃しお 🩵✨ 3D Yuri Wedding 2026 (npub1rzf…w4kn) 🩵｜We are Tokyo Hacker Girls (npub1k6r…8c3g)

Model https://x.com/NananoNanase
Design https://x.com/shiranui_illust
PFP https://x.com/7783__
🦋 @lina.yt
📨 lina@lina.yt
💲https://lina.yt/sponsor

YouTube: https://lina.yt
Twitter: https://lina.yt/twitter
Bluesky: https://lina.yt/bsky
GitHub: https://lina.yt/gh
Sponsor Me!: https://lina.yt/sponsor
Buy me a Ko-Fi!: https://lina.yt/kofi

Public Key

npub1cxqje22r8ewnr30rt625d58cr8gpdjnw405cq5765m2qsvghnmpquz6wtz

NIP-05 Address

lina_at_vt.social@momostr.pink

Profile Code

nprofile1qqsvrqfv49pnuhf3ch34a92x6rupn5qkefh2h6vq20d2d4qgxyteasspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsrqspcd

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1cxqje22r8ewnr30rt625d58cr8gpdjnw405cq5765m2qsvghnmpquz6wtz

Show more details

Last Notes

2026-05-12 15:03:02 UTC

🚀 IT WORKS!!!! 🚀
ARKit iPhone face tracking, without an iPhone. Just a webcam on any Mac.
All the blend shapes. All the features. No magic camera required. It just works.
Now I just need to plug this into VBridger/VTS and clean things up a bit ✨
Logs: https://gist.github.com/hoshinolina/ba7548a50563146fa1caf3d2bd8ea3be
https://media.vt.social/media_attachments/files/116/562/184/028/866/183/original/cc2979e62d14d28f.png

2026-05-07 08:19:27 UTC

- reply

> Can it be met?
"I can't realistically do what I want without violating the license" does not, in fact, mean you get to violate the license.
> Also if a document can be legally read, then why can it not be used for training?
This is the "ML erases copyright" argument. The point of copyright safe models is not assuming that model is valid.

2026-05-06 07:30:28 UTC

- reply

This is rootful and publishPort does not work with internal networks. That's the whole reason I ended up here. Don't ask me why.

2026-05-06 06:31:23 UTC

- reply

If the model weights were licensed CC BY-SA themselves and the source training data were thoroughly documented and attributed (that's the BY part) then of course it would be a legitimate derivative work of the training data.
That is not the case. Not a single ML model I've found is attributing anything to its training data to copyright standards, nor considering things like license incompatibilities.

2026-05-06 03:30:54 UTC

- reply

OK so apparently setting DNS to 0.0.0.0 means setting the upstream DNS so that works to close off DNS.
And then I can use firewall-cmd to configure container networking policies, except for some reason the firewall zone is hardcoded to "trusted" by podman so I have to use that one...???

2026-05-03 23:53:53 UTC

- reply

Not to argue with the general point, but I don't think those block diagrams are useful to making it. The DDR one is basically just "this is a DDR memory block" with no detail.
DDR is more complicated in terms of control logic as far as I know, and modern versions like LPDDR5 *also* have on die ECC (not because radhard, just because the bits are so dense they finally stopped being able to pretend perfect memory is practical, long after flash/etc had to).

2026-04-21 03:55:28 UTC

Well this is ✨interesting✨!
Turns out, macOS already supports what it needs to run Intel binaries with a non-Rosetta emulator, after Rosetta dies.
It's behind a private entitlement for now, but still!
Wine+FEX+ARM64EC anyone? ^^
https://media.vt.social/media_attachments/files/116/440/663/385/326/510/original/864a6e3222c30852.png
https://media.vt.social/media_attachments/files/116/440/663/553/078/399/original/01e9e8ecd9c80188.png

2026-04-16 07:04:52 UTC

A friend asked Gemini to do a security assessment of a recent open source macOS app (look through code, developer behavior, user forums, etc).
It spat out a 2,500 word essay painting the whole thing as a massive backdoor, talking to C&C servers, reading your chat messages, bypassing macOS security, the works. Entirely coherent on the face of it, overdone but it *could* have been real and someone not in infosec would easily buy it.
100% hallucinated. Gemini wrote an entire infosec fanfic based on nothing. Worst thing I found on the real repo was a symlink traversal bug that was quickly fixed by the dev.
This was using the "Deep Research" function in "Pro" mode on an "Ultra" account.

2026-03-31 12:34:23 UTC

- reply

Try the COPR here!
https://copr.fedorainfracloud.org/coprs/hoshinolina/streaming/
After enabling it, just `sudo dnf install proaudio-setup` and rebooting should do the magic. You can run `sudo proaudio-setup check` after to verify that everything is configured properly.
Let me know how it goes!

2026-03-26 08:14:34 UTC

TIL Linux loses IRQ SMP affinity configuration when you sleep/resume (x86). This seems... less than ideal?

2026-02-19 14:51:36 UTC

Okay so I finally got around to reading the Fluxer dev's (long!) blog post and... his take on federation is literally the exact same thing I independently suggested.
10/10 this guy knows what he's doing. This is going to work.
(Also fully agree with his "why not E2EE for messaging" section)
https://media.vt.social/media_attachments/files/116/097/853/738/250/531/original/0d42d9ce205a4af4.png

2026-01-03 02:03:37 UTC

I'm spiraling a lot this morning again... thinking about how nobody in the entire Linux Graphics community stood up for me really, really hurts. Not even close friends.
I don't post about this stuff often but that doesn't mean I'm not suffering...

2025-12-05 07:01:15 UTC

Honestly, some days I wonder if I should just switch to Windows... what's the point of an OS built around a kernel that is this toxic?

2025-12-01 04:36:24 UTC

RE: https://vt.social/@lina/115431232807081648
Addendum to this whole thing: I learned that Karol is telling people that there is evidence against me, but that sharing it would put people in danger, so he can't.
In effect, this means that the Freedesktop CoC team is actively choosing to judge people based on secret evidence, without giving them any opportunity for due process or defense.
For whatever it's worth, I have no idea what that evidence could possible be. It might be forged, or unreliable. I am deprived of any opportunity to defend myself against it.
Needless to say, this is not how any CoC team should conduct itself, and every member of and contributor to the Freedesktop ecosystem should be concerned. What happened to me could happen to anyone.
#note1h82…mg9c

2025-09-21 05:03:01 UTC

- reply

I'm actually kind of wondering if I got into this habit partially to make things easier to see on stream, and then it stuck because it's more comfortable! ww

2025-09-21 04:59:51 UTC

I just realized something... When I use HiDPI monitors, I often end up zooming in websites, text editors, and consoles. But I don't want to set the display scale larger (than 150%), because I want menus and widgets to stay smaller. I want the main content area to be easier to read, but keep things around it denser since I don't look at them as often.
Does anyone else do this? Should it be some kind of system setting even? ^^

2025-09-12 08:46:18 UTC

- reply

My personal opinion is that non-generative AI is not copyright-transitive the same way software is not copyright-transitive.
A Word document does not carry the copyright of Microsoft Word, because Microsoft Word is just a tool providing non-creative input to the document.
An AI model for face detection does not carry the copyright of the training data, because the training data is just a tool providing non-creative input to the model.
The training data *might* have been used in violation of some terms or license, but that is a *different* question to whether the resulting model itself is infringing on its copyright. Just like using a pirated version of Microsoft Word doesn't make the documents you make with it copyright violations.
It's GenAI where things change, because the output and the functionality of the model becomes (ostensibly) creative. And that's what copyright cares about, creative works.

2025-08-23 04:05:32 UTC

- reply

I should try this....

2025-07-22 07:56:46 UTC

For anyone working in Japan or considering it: YSK your visa is NOT tied to your employer:
- You can freely leave and find another job.
- You can stay job seeking for the duration of your current residence permit.
- You can be self employed with local clients.
Some employers lie about this, don't fall for it, and NEVER give them your residence card! It's yours, not theirs!
Nobody is going to kick you out of the country just for losing your job. Know your rights.
As long as you follow the rules, pay your social security, pension, and taxes, and make enough to earn a living in Japan, immigration generally does not care about what you're doing.
There is paperwork to be filed and laws to follow, but as long as you do that, you can stay!

2025-05-27 11:35:59 UTC

Looks like a 20-core (16p 4e) M1 Ultra (2022, 3.0GHz) is slightly faster than a 16-core (32-thread) AMD Ryzen 9 7945HX (2023, around 4.3GHz real clock) at building Chromium/CEF.
The M1 Ultra is pulling ahead by around 5% in terms of source files, right now.

2025-05-05 05:16:40 UTC

For over one year I've been harassed, threatened, doxxed, misgendered and abused by Luna the Foxgirl, author of Inochi2D.
Due to her attacks and manipulation of others, I no longer feel safe contributing to Linux GPU drivers, and I will be retiring my current model.
https://asahilina.net/luna-abuse/

2025-04-02 06:46:19 UTC

- reply

They keep crafting new accounts...

2025-04-01 17:10:37 UTC

- reply

https://vt.social/media/media_attachments/files/114/263/814/026/420/779/original/67ccf1154e8bf679.png

2025-04-01 17:08:14 UTC

- reply

There's a huge DM spam wave from Nicole, the Fediverse Chick... google it ^^

2025-04-01 17:00:20 UTC

I really should just throw a quick patch onto vt.social to reject messages containing "Fediverse Chick"...

2025-03-22 09:26:51 UTC

- reply

No other open kernel has the hardware support to really be a Linux alternative... the BSDs will work for some things, but there is a huge difference in hardware support, especially for desktop and embedded. Things like Redox are essentially at the research kernel stage and not practically usable yet.
You can drop in another init system and write a few init scripts and switch to something other than systemd, but I think Linux is a de facto monopoly right now...

2025-03-20 10:30:42 UTC

- reply

If you don't believe me, look at what happens when you configure an EQ with a reeeeally high Q (super steep/complex frequency response), and play back a click through it!
https://vt.social/media/media_attachments/files/114/194/293/504/019/267/original/159fd79ec11da4c4.mp4

2025-03-20 10:18:40 UTC

I was thinking about DSP stuff in another thread and it just hit me that... an EQ can be expressed as a FIR filter, and a reverb impulse response is the same thing, and you can go back from the IR to its frequency response.
That means a reverb filter and an EQ filter are actually the same thing. A reverb is just a really complicated EQ. 🤯
(I know some/many EQ filters are IIR, but they can always be approximated well enough as a FIR with enough taps)

2025-03-18 15:25:41 UTC

For personal reasons, I no longer feel safe working on Linux GPU drivers or the Linux graphics ecosystem. I've paused work on Apple GPU drivers indefinitely.
I can't share any more information at this time, so please don't ask for more details. Thank you.

2025-03-16 23:59:50 UTC

- reply

Those things just work for me on KDE Wayland, it's X11 that is kinda broken... ;;

2025-03-12 12:45:11 UTC

- reply

Are you doing the math in the Y/C domain or some other colorspace? I get the feeling the best way to try to approach this would be to take the raw 7800 color values (4+4 bit) as input, build up a line buffer of the composite color signal with a lot of oversampling, and then try different mixing approaches for Y/C and pulse shaping/delays for the input signals. Then you run it though a composite decoder to produce YUV/RGB only at the output.
Once you have something close with that method you could probably optimize it to be less brute force, and at that point you could generate as many samples as you want since you'd have a reference implementation ^^

2025-03-12 10:39:57 UTC

- reply

Did you read this page? Apparently both the generated colors and the artifact colors vary from console to console and even with temperature... so I'm not even sure if there's such a thing as a proper ground truth!
https://7800.8bitdev.org/index.php/Atari_7800_Color_Documentation

2025-03-11 15:35:28 UTC

- reply

By lookup texture I meant for the color mixing. So like, if you manage to get enough data points to have a reasonable dataset of how different colors mix together, it could just be implemented as one or more textures indexed by luma/chroma or some derived components if you can't come up with an analytical construction that's accurate enough.

2025-03-11 15:09:48 UTC

- reply

I think you're going to need more data for this... have you compared output of RF machines vs. composite or s-video modified ones?
I think there are too many factors involved to figure it out from some game screenshots... what I would do is create a bunch of test patterns with many colors/artifact patterns, try them out on a real machine (or multiple, with different output setups), and use them to try to figure out what the color mixing curves/function is. At the end of the day you could even just turn it all into a lookup texture.
Here is some discussion on some of the subtleties of the TIA video output: https://www.retrosix.wiki/tia-video-faults-atari-2600 (since you're dealing with mixing the chroma and luma signals, those subtle timing issues probably play a part in how they mix)

2025-03-08 20:11:24 UTC

- reply

It is a nothingburger. It's basically "if you can write firmware for the device and access the Bluetooth HCI (host) interface, you can do undocumented things outside of the Bluetooth spec". To access the HCI interface you need to already be writing custom firmware.
It's not a remote attack, it does not bypass firmware signing. The things you can do are things you can already do with various other hacked/special-purpose devices, or an SDR.

2025-03-02 14:50:20 UTC

- reply

If you want true horrors look at GPU ISAs... ;;

2025-02-03 16:36:54 UTC

How do you change the frame rate to a simple constant and properly regenerate timestamps with ffmpeg, without transcoding or duplicating or dropping any frames?
Every time I try to do this, the only way that works is converting to a raw bitstream format and back. Is there really no way to tell ffmpeg to just throw away all timestamp and FPS information and just recreate it from scratch?
The closest I got is -bsf:v setts=ts="N/TB_OUT/30" but that only changes the timestamps, not the container timebase/frame rate, so it still shows up with weird numbers like 17.42 fps, 17.42 tbr, 1k tbn. I tried -r, -video_track_timescale but they don't work.
I ended up doing it with mkvmerge, which is super easy: mkvmerge -o out.webm --default-duration 0:30fps input.webm. This does what I want, which is clean timestamps with no weird rounding errors or duplicated frames at the beginning/end and a proper timebase 30 fps, 30 tbr, 1k tbn. But it means I need to round-trip through mkv if the container is something else...

2025-01-31 21:35:44 UTC

Cyan: Babe can you make me a sandwich?
Me: Sure! Do you want it hot or cold?
Cyan: With lots of Lao Gan Ma, hot.
Me: ...I meant temperature...

2024-12-05 21:38:41 UTC

Me: You know what I want now?
Cyan: What?
Me: Chocolate~
Cyan: What do I look like, a cacao tree??
Me: ........ Σ（・□・；）

2024-10-28 12:25:19 UTC

I've seen this one come up a few times in PL threads too... despite what some believe, Go is not a memory safe language!
Specifically, Go is not memory safe if your program uses goroutines. Go does not protect against data races, which trigger UB and memory unsafety.
See: https://go.dev/doc/faq#atomic_maps
Also: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html

2024-10-22 16:10:15 UTC

I just hit 1K followers!!! Thank you everyone!!!!! 🩵🩵🩵
It's crazy how fast things are growing here on Bluesky!! How long will it take to hit 2K? 🚀
https://vt.social/media/media_attachments/files/113/351/938/349/457/310/original/c24cc33856c25019.png

2024-10-19 19:08:30 UTC

x112virtgpu is so cursed!!!
Today we somehow ended up more broken than we started... ^^;;
More debugging next stream~!

2024-10-18 09:33:30 UTC

- reply

Please read the rest of my thread. It's not just about it being *possible* to delegate nested deinit to an object, it's about the compiler writing that deinit code for you most of the time. I don't want to have to manually write a deinit function for a complex object with 20 members.
On top of that, just because you *can* do that with Zig doesn't mean the language encourages it. The standard library types don't do it, and you're stuck manually writing cleanup code as I said.
At the end of my post I already said I'm not saying Zig is a bad language, but it definitely isn't the right language to bring to the Linux kernel because it doesn't solve the problems we're trying to solve.

2024-10-18 07:52:22 UTC

- reply

Copying a thread I tweeted about `defer` vs. `Drop`:
> with defer:
> - whilst a bit error-prone, destruction is bound to the context and you can have non-intrusive destructors, you'll need this for APIs where you need a context to destroy a resource, so storing it in each object is infeasible
This is a valid argument and I actually have run into this myself! It's a real annoyance in Rust...
... but the thing is, this is the exception, not the rule. 99% of the time automatic Drop is what I want.
One of the neat demos I did of how Rust is better than C is that my Rust OF abstractions take care of refcounts for you, even across iterators and such. All the explicit refcounting (that nobody gets right) disappears.
In Zig, it'd come back, just as "defer" everywhere instead.
It *is* possible to forbid Drop in Rust for a type and require explicit destruction, and I'd rather do that for the 1% of cases where I need it, than have to defer the other 99%.
The Zig approach really doesn't scale for complex data structures. You can't have a generic vector or map, and just destroy it. You need to write explicit code to iterate through it and destroy every element. That's a real major pain...
Much of the time I don't even have Drop impls for my objects, or they just do one trivial thing. 99% of the cleanup code is generated by the compiler recursively calling Drop on all contained types. Having to type that out would be a lot of time wasted writing error-prone code...

2024-09-11 06:20:36 UTC

Cyan: 4000 messages that day... how many seconds per message is that?
Me: *Thinks for 5s* about one message every 20 seconds
Cyan: *ignores me, uses a calculator*
Cyan: ~20 seconds per message...
Me: Told you
Cyan: How did you do that??
Me: 86400 sec per day / 4000...
Cyan: o_o

2024-09-11 05:56:18 UTC

- reply

Also note the scale, there's probably 100 or so messages one of those "zero" days ^^

2024-09-11 05:53:14 UTC

- reply

You don't need chat when you're together 24/7 www

2024-09-11 05:46:26 UTC

Yes, I'm a total nerd and I analyzed my chat history with my gf @npub1rzf…w4kn~💙💙
Total messages: > 51,000
Highest peak: 4,254 / day
Average over 2 months: 733 / day
3 days until our stream~ #AsaCyan
Send us questions here! http://cyan.yt/qa
https://vt.social/users/lina/statuses/113104093914716150
https://vt.social/media/media_attachments/files/113/117/314/449/076/834/original/6f68b8db1b074a73.png

2024-09-09 22:28:39 UTC

4 days until our stream~ ✨
Each day we'll share a secret slide from our presentation! 💙
https://vt.social/users/lina/statuses/113104093914716150
https://vt.social/media/media_attachments/files/113/109/953/223/865/861/original/5423efbdfd656708.png

2024-09-09 11:19:02 UTC

- reply

Oof...

2024-09-09 10:52:45 UTC

- reply

Maybe you can script it somehow?

2024-09-05 10:05:42 UTC

Was looking into lobste.rs since I thought it might be more reasonable than reddit/HN... and the first comment I see on an article about me is (very obviously) deliberately misgendering me. Oh well, I guess not...

2024-09-04 10:54:26 UTC

- reply

GPU TLB invals used to be broken when running under the m1n1 hypervisor (which confused me to no end...) and the symptoms were... interesting...
At one point, for one demo, I used a workaround of waiting for the GPU to power down after every command since that would implicitly flush the TLBs ^^;;
The funny thing is macOS almost never broke without TLB invals because its allocation policy masked most of the issues by accident.
TLB invals on AGX are... weird. You literally use a CPU TLB inval instruction. Yes, really, passing in a GPUVA and a GPU ASID... it's like they intended for this to be used with HMM... except they forgot to extend the GPU address space size to the same bits as the CPU so we can't do that!
On my driver this causes GPU TLB invals to potentially randomly invalidate live CPU TLB entries, but this seems to be fairly harmless in practice (minor perf hit I guess). It could be avoided by reserving ASIDs for GPU use only, but I don't want to open the can of worms of somehow interfacing between the GPU driver and the core ARM64 ASID allocation code.

2024-09-01 16:58:07 UTC

- reply

I think it was a mistake to ask existing maintainers to review the Rust abstractions for their subsystems.
On paper that makes sense, due to the magic undocumented semantics since the docs are terrible. But that only works if those maintainers are *actively* helpful and willing to learn new things and see things from a different perspective.
We'd have been better off designating Rust maintainers for each subsystem and not allowing the C maintainers to gatekeep everything. Then they can choose to help review and get the semantics right, or not. But they wouldn't have the power to just block everything and force things to be done "their way" or delay merging until everything goes through an agonizing process that boils down to teaching how Rust is supposed to work to someone who doesn't want to learn.

2024-09-01 16:50:56 UTC

- reply

So far I haven't really seen any real active, positive, legitimate enthusiasm about this from any maintainer involved in the upstreaming process. At best it's indifference. Most of the time it's questioning everything.
Some people manage to put on a polite face but their interactions are still completely unproductive and it's obvious that deep down they don't really want to help or understand, they just want to gatekeep and not learn, and make things painful for the Rust team.
And then we have the outright abuse, like what happened with Wedson's presentation.
When Linus merged Rust I was hopeful he'd help push things forward when maintainers were unhelpful... but he hasn't really done anything.
I still think Rust for Linux will happen. The benefits of Rust are real and clear to anyone who actually cares to understand them.
But it's going to take a lot longer than necessary, and burn a bunch of people out in the process.

2024-09-01 07:44:17 UTC

- reply

It's an execution context issue. If the scheduler itself is what is cleaning up the job then the job ends up triggering the refcnt to go to zero, then that tries to free the scheduler while this code is actually being run by the scheduler.
The fix is to defer the cleanup/refcnt drop to another thread... but heavyweight stuff like managing deferred work is something to be avoided in Rust abstractions, which are supposed to be fairly lightweight and not involve stuff like that.

2024-08-31 22:56:20 UTC

- reply

The claim is that the hw_fence needs to keep the scheduler alive. So it has to hold a reference. If the driver no longer needs the scheduler, then it would drop its top-level reference, leaving only the hw_fence reference, and then that would deadlock when it is dropped.
> If the driver dropped its scheduler ref, wouldn't the scheduler only be dropped if there was nothing left in the workqueue ("But the scheduler also keeps track of jobs, which reference their completion fences" -> nonzero job_cmp refcnt)?
The jobs hold a reference to the job_completion_fence but *not* the only reference. Queueing a job returns a reference to the completion fence, and that fence lives on and possibly gets sent to other drivers entirely. The job_completion_fence has to be able to outlive the jobs since it continues to exist after jobs complete (its job is to signal that completion). So if the driver no longer needs the scheduler and drops its main ref, then later the last job_completion_fence to be dropped would actually trigger the scheduler to be destroyed per the above mechanism, and the deadlock.

2024-08-31 16:31:06 UTC

- reply

I don't think you appreciate the classes of bugs that Rust eliminates. "Memory safety" isn't just "don't have buffer overflows". It's also eliminating multithreaded race conditions. Missing locking problems. Complex codepaths that lead to an accidental UAF.
Quite frankly, if you review complex C code that is called across multiple threads and you don't spend a signficant amount of time thinking about those things... you're probably not doing a good job reviewing it.
How thorough a review would be required to catch the race condition UAF bug that I describe here?
https://github.com/AsahiLinux/linux/issues/309#issuecomment-2239280107
That code clearly went through review but it wasn't caught. In fact I dare say hours of additional review would probably not have caught that bug. You have to spend large amounts of time simulating potential execution scenarios in your head to catch it. It took me a long time to even understand it with the crash traceback in front of me.
That bug is impossible in safe Rust.

2024-08-31 13:47:11 UTC

- reply

If it protects against 70% of subtle bugs, that's 70% of fewer things to worry about during a review. That means you either need less scrutiny or you can spend the review bandwidth on the other 30% instead. Either way you end up with higher code quality, lower review burden, or both.

2024-08-31 12:03:16 UTC

- reply

To be clear, I don't blame Linux developers for the incomplete docs. For better or worse, the Linux kernel is very complex and has to deal with a lot of subtlety. Most userspace APIs have much simpler rules you have to follow to use them safely. Kernels are hard!
Even experienced kernel developers get these things wrong all the time. It's not a skill issue. It's simply not possible for humans to keep all of these complex rules in their head and get them right, every single time. We are not built for that.
We need tooling to help us.
The solution is called Rust. Encode all the rules in the code and type system once, and never have to worry about them again.
Just like the solution to coding style arguments is to encode all the rules in an auto formatter and never have to worry about them again (hint hint! ^^)
And then we can stop worrying about all the low-level safety, ownership, and locking problems, and start worrying about more important things like high-level driver and subsystem design.

2024-08-31 11:44:54 UTC

- reply

In the end, coding kernel code in Rust is a *huge* change from coding C. With C you have two options:<li>Wing it and either hope reviewers catch it or suffer debugging subtle oopses</li><li>Spend hours understanding the code before you dare use it, and hope you caught everything.</li>
This adds extra reviewer and maintainer workload too! It means that they need to review submissions to ensure they follow all these hidden rules that aren't documented. Sometimes they miss things. Sometimes the problem is major enough the code needs a big refactor.
All that just goes away with Rust. Poof. Gone. If it compiles it's safe and won't oops or leak references (except unsafe code, but then you only have to review THAT and the rule is it has to be carefully documented).
Of course we still need code reviews, and help from experts in specific subsystems. Rust doesn't magically make code perfect.
But it does get rid of all the silly low level problems and mistakes, so you can focus on the high level ones.

2024-08-31 11:44:45 UTC

- reply

But the end result of all this is that you CAN, in fact, just look a the Rust API and know how to use it correctly for the most part. You never have to worry about reference counts, about NULL pointers, about forgetting to check results, about dropping refs in error cases.
You never have to worry about holding the right locks, about accidentally forgetting to take a ref or dropping it twice. You never have to wonder how error returns are encoded.
Because if you make a mistake with these things, your code won't compile.
Of course you can still misuse APIs, but the worst that will happen is that you'll get an error return, or maybe a deadlock (deadlocks are easy to debug with lockdep and I wrote a really neat Arc<> integration to catch potential drop/decref related locking errors).
Even with APIs that mostly are fairly rigorously documented (OpenFirmware/Device Tree comes to mind), following all the rules in C is often tedious and error prone. Look at some random OF code in a driver and there's a good chance it leaks references.
(This doesn't really matter for most systems since they don't compile kernels with OF_DYNAMIC so ref counts are ignored, so this never gets noticed and fixed.)
But with my OF Rust abstractions? They do ref counting for you. You can just forget about it.

2024-08-31 11:44:22 UTC

- reply

Sometimes these requirements were reasonable, just unwritten. Sometimes they were a bit too flexible/wild and I had to make some opinionated decisions when writing the Rust abstractions to narrow it down to a safe usage.
Sometimes I had to add extra locking inside the abstraction in order to make it practical to make safe. Sometimes I had to make some small changes to the C side to make it more orthogonal or logical and usable, e.g. to expose an unlocked function to be used with a lock taken.
Sometimes the locking was subtle enough that while I was able to write a safe Rust abstraction, it came with a big doc comment explaining how you have to be careful with usage and drop order to avoid deadlocks (deadlocks are "safe", Rust doesn't inherently protect against them).
Sometimes it was a lost cause without making the C side more reasonable (drm_sched only, really).
However, most of the time the compromises made when writing the Rust abstraction point at issues with the C side design and how it could be improved.
In general the approach is "write the Rust side making as few changes to the C side first to avoid conflict, then maybe propose changes to the C side based on lessons learned" (we haven't really gotten to the second part yet at all).

2024-08-31 11:44:04 UTC

I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves the problem.
I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to its API.
Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?
When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?
Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument?
Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?

2024-08-31 08:49:10 UTC

- reply

Here ^^: https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html

2024-08-30 21:05:03 UTC

[From Jason Gunthorpe](https://lwn.net/Articles/987817/ ), maintainer of 5 Linux kernel subsystems:
> IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.
Today I learned that my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".
(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau to GL 4.6 conformance.)
I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...

2024-08-30 15:29:36 UTC

- reply

I used the DRM scheduler because I was told it was the right choice at the time, and because it handled the thread/workqueue stuff internally and there were no Rust workqueue abstractions at the time. Now it turns out that to make scheduler usage safe I would have to use workqueues inside my Rust abstraction anyway (and introduce a bunch of spurious extra references to ensure soundness), which is completely crazy.
Rust workqueue abstractions now exist, so the path forward is clear: ignore drm_sched and write my own scheduler in Rust using its own workqueue, without any of the lifetime craziness (and all the bugs it brings, I haven't even begun talking about the many internal drm_sched memory safety bugs affecting all drivers which I've been running into...).

2024-08-30 15:29:20 UTC

- reply

Then the second, related patch:
When you destroy a scheduler, what if there are still jobs pending or running? The logical thing to do would be to abort pending jobs, and signal running jobs to error, or some sort of cleanup like that. What does the current code do? Nothing... it just crashes.
I fixed it so that tearing down the scheduler gracefully aborts all jobs and detaches the hardware callbacks (it can't abort the underlying hardware jobs, but it can decouple them from the scheduler side). In my driver's case, that all works beautifully because my driver internals are basically reference counted everywhere, so while the scheduler and high-level queue can be destroyed, any currently running jobs continue to run to completion or failure and their underlying driver resources get cleaned up then, asynchronously.
The maintainer rejected the patch, and said it was the driver's job to ensure that the scheduler outlives job execution.
But the scheduler owns the jobs lifetime-wise after you submit them, so how would that work? It doesn't. If you try to introduce a job->scheduler reference, you're creating a loop again, and the scheduler deadlocks when it frees a job and tries to tear itself down from within.
So now we're back at having to introduce an asynchronous cleanup workqueue or similar, just to deal with the DRM scheduler's incredibly poor lifetime design choices.

2024-08-30 15:29:03 UTC

- reply

But the scheduler also keeps track of jobs, which reference their completion fences, so we have a lifetime loop. That loop is broken at certain points in the job lifecycle, but the fact it exists makes it very difficult to reason about the lifetimes of any of this stuff, and also makes it impossible to implement the requirements imposed by drm_sched via straight refcounting. If you try to refcount the scheduler and have the hw fence hold a reference to it, then the whole thing deadlocks, because the job completion fence might have its final reference dropped by the scheduler itself (when a job is cleaned up after completion), which would lead to trying to free the scheduler from the scheduler workqueue itself.
So now your driver *needs* to implement some kind of deferred cleanup workqueue to free schedulers possibly forever in the future. And also your driver module might be blocked from unloading from the kernel forever, because if any buffers hold on to job completion fences, that means your driver can't unload due to the dependency.
This is just bad design.

2024-08-30 15:28:45 UTC

- reply

The conflict on the ML happened around two related patches:
First, I fixed a bug where the scheduler job completion fence had some debug callbacks that would dereference the scheduler object itself. That would mean that the scheduler would have to outlive its fences. This makes *no sense* because fences are long-lived objects: your fence might be attached to a buffer shared to another driver entirely and could be alive forever. Introducing this job completion fence -> scheduler lifetime dependency is silly, because the scheduler is an object owned by one driver. That means that driver, and the structures it associates with a scheduler, might be blocked from cleaning up forever. And this all just due to some debug pretty-print name callbacks! It wasn't even critical core functionality or some deep design decision, just some debug code. But the maintainer blocked it because he believed it was required, and sensible, to have the scheduler outlive its completion fence.
But wait, how do you even do that? If it's the driver's job to ensure that lifetime, but the completion fence is owned by the scheduler, how would that even work?
The answer is that the job completion fence *holds a reference to the hw fence*, even after the latter completes. And *that reference is supposed to cause the driver to keep the scheduler alive*.
So now we have a lifetime chain of job completion fence -> hw fence -> scheduler.

2024-08-30 15:28:22 UTC

I'm going to describe the drm_sched mess because honestly, I think it needs to be documented outside of the mailing list arguments which are honestly painful to read.
A "fence" is just an object that can be signaled, waited on, and have callbacks attached to it. It is used to signal completion of some process between different pieces of code (some GPU work finishing might trigger more GPU work or a frame to be displayed on the screen).
The concept behind drm_sched is relatively simple. You create a scheduler (ignoring entity/rq stuff, I use it 1:1 with schedulers). Then you create jobs, which might depend on other things via attached fences.
When you push a job into the scheduler, you transfer ownership of the job into it, and receive a scheduler fence representing job completion. The scheduler's job is to wait on the dependency fences of the oldest pending job, then once they signal ask the job whether it is ready to run (which might return another fence to wait on for busy hardware resources), then once that is ready, actually call the job run callback. That callback returns another fence representing hardware completion (the "hw fence"). The scheduler then arranges for that fence, when signaled, to also signal the job completion fence that it associated with the job (the "job completion fence"). The scheduler can run multiple queued jobs in parallel. As jobs complete in the hardware, they signal their hw fences, and the scheduler cleans up and frees the job objects.

2024-08-29 13:05:55 UTC

I regretfully completely understand Wedson's frustrations.
https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/
A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.
When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.
That simple concept only recently finally got merged, over one year later.
When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".
My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".
Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.
One C driver works, so Rust drivers must work the same way.