Notices by Christian Brauner ?? (brauner@mastodon.social), page 3

@corbet Any specific example that triggered this?

I can probably mange to free up another 8 bytes in struct file by killing f_version and moving it into the few filesystems that care about it.

That would give us back 8 bytes for future expansions.

It's a rough draft and lacking commit messages but it should work (famous last words)...

https://github.com/brauner/linux/commits/vfs.file.f_version

#linux #kernel

I just added nine new EINVALs to the move_mount() manpage...

That commit message

kernel test robot noticed a 9.1% improvement of stress-ng.sockfd.ops_per_sec on:

commit: d9f21b3613337b55cc9d4a6ead484dca68475143 ("af_unix: Try to run GC async.")
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9f21b3613337b55cc9d4a6ead484dca68475143

is very scary to people who remember the "pleasantness" we've already gotten out of this codepath.

I'm done writing groff.
https://github.com/brauner/man-pages-md

fyi https://fosdem.org/2024/schedule/track/kernel
happening rn.

I hadn't read that commit message until now. 😅

Hey #Linux #Kernel people. Last year we had the first #Kernel Devroom at #FOSDEM. And we're running the #Kernel Devroom for #FOSDEM in 2024 as well!

#FOSDEM 2024 is taking place over the weekend of the 3 & 4 February in Brussels, Belgium!

It is a wonderful event that's very close to my and a lot of people's hearts!

Join @rppt, Daniel Borkmann, and @stgraber, and myself and make this another great #FOSDEM!

We're very excited for your submissions!

https://lists.fosdem.org/pipermail/fosdem/2023q4/003536.html

It's wild to me that we keep putrified architectures around in #Linux for that long in the first place. And then when we finally remove it people argue for them to be put back in.

I really have a hard time understanding this.

I had one of those ia64 servers at home for about a month which I actually picked up from someone in Berlin just to fscking test copy_thread() changes in 9ba27414f2ec

https://lwn.net/Articles/950466/ #LWN #ia64

Yes, #systemd switching everything over to #pidfds.

* Most of the internal process tracking is being changed to use PIDFDs instead of PIDs when the kernel supports it, to improve robustness and reliability.

https://github.com/systemd/systemd/blob/main/NEWS

One thing that I end up doing is generating mails/pull requests with fixed message IDs.
This allows me to refer to mails via lore links before they are sent. For example, to mark PR dependencies.

Problem is that they could be grabbed by someone else if I don't send them all at the same time.

Maybe lore could allow reserving message IDs for 24h or sm? @monsieuricon

@brenns10 @monsieuricon oh yeah, good point. Like <bliblablub@brauner> or sm

@brenns10 @monsieuricon the advantage being that I'm already doing:
<DATE-1stword-2ndword-RANDOM@brauner>

@brenns10 @monsieuricon https://github.com/brauner/git-send-email-custom-message-id

I have this weird behavior where I try to setup a loop device on a syzkaller enabled config and losetup -f --show just hangs for an insane amount of time before it succeeds. Has anyone experience this?

@kernellogger Fun excercise: Find out how many filesystems exist on Linux. Feel free to exclude any internal filesystems (e.g., sockfs, pipefs, etc.). You should be > 65.

Apparently I'm not a maintainer of #LXD anymore and neither is @stgraber. So it seems from now on it's Canonical employees only.

I'd like to point out that before Canonical moved LXD into github.com/canonical/lxd maintainership was completely independent of the company. If you went to work somewhere else you still were a maintainer. As it should be with any well-functioning OSS project.

I think everyone knew that this was imminent. I'm relieved that @stgraber left Canonical. He deserves better! than this vengeful treatment! I'm proud of him and the team he's built!
https://stgraber.org/2023/07/10/time-to-move-on

LXD is a registered trademark of Canonical so while it would have been possible to maybe fork it, it at least wouldn't have kept its name. See https://ubuntu.com/legal/trademarks
However, Canonical has no control of LXC, LXCFS, or https://github.com/lxc
These projects way predate Canonical.

As of yesterday, the #LXD project is no longer part of the Linux Containers project but can now instead be found directly under Canonical's control.

Please read our official statement on:
https://linuxcontainers.org/lxd

I personally consider Canonical's move to be a hostile act and as far as I'm concerned the decision was unilateral. It may be legally sound but it leaves a very bad taste behind.

I've been involved with this project independent of what company I moved to. To see this happening is sad.