@kernellogger no, it just assumes if you log in via the X windows console, and your session has the right to reboot the machine, so does your xterm windows.

I ssh into my dev boards as root and reboot via that session. The issue is when I think I'm ssh'd in and go to reboot, I don't always notice the prompt is different and I can type `reboot <enter>` dangerously fast.

I usually add this to my .bashrc file to all my work machines.

alias reboot='echo "Wrong window idiot!"'
alias halt='echo "Wrong window idiot!"'
alias shutdown='echo "Wrong window idiot!"'

But I just learned, that I never added it to my Google workstation 😛

The blog on the responses from the Linux Plumbers survey is now published. https://lpc.events/blog/2022/index.php/2023/01/06/lpc-2022-attendee-survey-summary/

@hergertme as for getting that information in the kernel. If there’s an elf section for it, it shouldn’t be too hard. We are already looking into it. The idea is to flag that the task has the sframe section available, and when perf wants a trace, it will set a callback of some kind, and when the task is about to go back to user space, the section will be mapped in and call the perf callback to with the user space stacktrace.

It doesn’t matter when the user space stacktrace happens inside the kernel, it’s not going to change.

@hergertme sframe is similar to ORC. I guess it we should take some time to do the benchmarks with and without frame pointers, on critical loads.

ORC has solved the issue for the kernel, but currently profiling user space without frame pointers is “interesting”.

@hergertme Is there a performance penalty with this?

And if sframe support becomes default (after it is accepted), then we could teach the kernel to do user space stack tracing without frame pointers.

@ljs @joel_linux RCU is simply broken down into three parts:

• grace periods
• quiescent states
• synchronization

A quiescent state is a time or action that guarantees all grace periods that were running at the time of the synchronization have finished (but you do not care about grace periods that started after synchronization).

If a link list protected by disabling preemption, then the grace period is when preemption is disabled, and the quiescent state is when all CPUs have scheduled. So you can remove an item from the link list (where all readers must have preemption disabled to read it), and then wait for all CPUs to schedule which guarantees nothing has access to the item, where you are now free to delete it without worrying that something is reading it.

That’s the simple case. There’s more complex cases, but it all comes down to the three parts above.

@joel_linux @ljs there's no good heuristic, either you have write fair or write unfair. There's one good alternative, and you already know what that is. 😉

@joel_linux @ljs
It's not about performance, it's about not locking up the system. rwlocks are short and fast because they can't be preempted so new readers can still block writers. rwsems can sleep so it's much more likely to have writer starvation.

Happy New Year to the new force of social media!

I also want to state that I do not dislike Rust. This is just me ranting about things I have grown accustom to as a developer who’s main programming language has been C for over 3 decades!

@jose_exposito As Rust is really good at inferring logic, I’m surprised that it couldn’t just infer the PartialEq trait for simple enums.

@michaelphamct @acmel I will admit that I should have just started to learn to program Rust before learning the details of its implementation. But, here I am ;-)

@michaelphamct @acmel

Yes, your book is probably better to learn the language. And I wouldn’t recommend the book I’m using to just learn to program in Rust. But I like the book, because I am interested in how rust works. I want to get as good at rust as I am with C. With most C programs, I can usually visualize what the assembly output would be. I don’t have that with Rust. And this book is useful to have in order to get that kind of understanding of the language.

@jose_exposito That should be the default. I’m finding that I’ll be adding lots of #[derive(...)] all over the place.

@vbabka OK, i got recursion working. I don’t know what went wrong before. Perhaps it detected right away that a bug in my code would do an infinite recursion and failed out. Unfortunately, it didn’t quite tell me what that infinite condition was :-(

Although I’m ranting here, I also want to add what I really like. The RUST_BACKTRACE environment variable creating a nice backtrace on assert!() errors, is really nice!

Another annoyance is that you can’t compare enums.

use self::Direction::*;
enum Direction { UP, DOWN, LEFT, RIGHT};

fn foo (dir: Direction) {
     if (dir == DOWN) { ... }  <<--- Error!
}

But instead you must do:

   if matches!(dir, DOWN) { ... }

@aissen Moves something ;-)

@vbabka I immediately got a “Stack overflow” and the println! only went 3 deep. Maybe it was smarter to know it would go further?