@Conan_Kudo @fedora I use VisionQuest2 for baremetal kernel testing :-) I think you saw the screenshot that I put while ago: https://social.kernel.org/notice/AnfOy9iKK7ZP1YNvfc

It's pretty cool setup and even has outboard gear (a real TPM2 chip) connected :-) I use it in kernel testing by build image with BuildRoot.

For any RISC-V board used for development I'd recommend to download its user guide and search if it can be put into SDIO boot mode with e.g. some PIN switches. That means that you can have the whole boot chain in SD card including U-boot and OpenSBI.

@wren3n it breaks the bits that i actually use :-) e.g. elevated commands (you can sudo in ex) and remotes. and plugins often makes it not work like vim i.e. make it something else than vim is. i've been a vim user since 1998 so in that time you get into habbits :-) actually a completely new thing but still modal is easier to get off those habbits. it's totally subjective thing really.

@dngrs thanks for responses. you're always beginner in something :-)

@mpdesouza different key strokes is not that confusing after a while. i still love (non-neo) vim for raw text editing, and different strokese actually help me to be aware which editor I'm using ATM :-) and helix has very intuitive contextual help system.

There's also PR for editorconfig so I guess that some day that will land too https://github.com/helix-editor/helix/pull/1777/

Plugin systems sort of make everything as a programming language. I like the simplicity of "opionated" features even if one knob that i'd like to be there is missing. It also gives guaranteed ubiquitos UX when i login to different systems as everything has the "same plugins".

With Rust I've accepted the reality that I cannot simply survive with plain Vim. So using more and more Helix with that. I don't GUI and I dislike NeoVim so Helix has started to stick on me over the last year more and more.

One feature that I like a lot in Helix is "no plugins" ;-) That's fresh. One thing that I wished it had, and thus not applicable for kernel development, is the support for ".editorconfig". Once it has that I can try to write a kernel patch with it.

#helix #vim #editor

@FSMaxB thanks i learned a lot from your answers! highly appreciate this!

@FSMaxB i'm not sure what i'm doing exactly yet i.e. learning ;-)

https://bsky.app/profile/andy.baio.net/post/3lapfmteyak2x

@SeanOMik I rarely use Arc, and rather end up using e.g. RwLock or something. It does not end up to be the best option often in the end. So yeah have to admit that it is also fuzzy... And I really just don't get so far any of the cell types. I can admit that I don't understand them :-)

@FSMaxB better to stop spamming here :-) anyway this was the best documentation for me ever for cells: "noalias/restrict". That nails them...

@FSMaxB Found a pattern for my current problem that compiles and works.

Creation:

        let vmctx = RwLock::new(unsafe { Arc::from_raw(vmctx_mmap.as_mut_ptr().cast::<VmCtx>()) });

Example use:

            Arc::get_mut(&mut self.vmctx.write().unwrap()).unwrap().regs[reg as usize] = value;

This whole topic gained my interest because I incorrectly first used Box here. In this case Arc is the solution because it does “just drop” instead of “drop + free” (Box).

@FSMaxB I solve that by

1. vmctx: *mut VmCtx
2. vmctx: RwLock::new(unsafe { vmctx_mmap.as_mut_ptr().cast::<VmCtx>() }),

Not pretty but this at least works :-) If there is some day something nicer that I get I’ll fix it up…

@FSMaxB This actually did not work

$ cargo b
warning: /home/jarkko/work/github.com/jarkkojs/polkavm/Cargo.toml: unused manifest key: workspace.lints.rust.unexpected_cfgs.check-cfg
   Compiling polkavm v0.15.0 (/home/jarkko/work/github.com/jarkkojs/polkavm/crates/polkavm)
error[E0308]: mismatched types
    --> crates/polkavm/src/sandbox/linux.rs:1596:13
     |
1596 |             vmctx,
     |             ^^^^^ expected `RwLock<VmCtx>`, found `RwLock<&mut VmCtx>`
     |
     = note: expected struct `RwLock<VmCtx>`
                found struct `RwLock<&mut VmCtx>`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `polkavm` (lib) due to previous error

I’m sure I can solve it just putting a note in order to not spread FUD ;-)

@dngrs OK fair enough. I rarely have anything with multiple owners. That is a good example I think thanks! I get that.

Cell types are still totally alien topic but maybe that will uncover some day :-)

@dngrs Someone explained me "in C" what UnsafeCell is: it is like restrict + noalias in C compiler set to a pointer. And it is mostly for constructing other Cell entities. So yeah now I get much better what they are :-)

@dngrs OK fair enough. I rarely have anything with multiple owners. That is a good example I think thanks! I get that.

Cell types are still totally alien topic but maybe that will uncover some day :-)

@FSMaxB I.e. I can put that then to RwLock<Foo> field in a struct. I tested and it worked! It might be also that I sometimes have redone some of e.g. cell functionality with PhantomData, i.e. I'm using "atoms" instead of "molecules" and thus I might be blind for the need perhaps... Still would be nice to see e.g. a presentation that would actually nail these (not a Rustbro Youtube tutorial video crap but something more in-depth).

@FSMaxB Nah I tested and I could ignore both and instead do:

        let foo = RwLock::new(unsafe { &mut *foo_raw.as_mut_ptr().cast::<Foo>() });

:-) If I have a Drop trait for Foo it’s pretty much what it needs to be.

dtrace.conf(24) is going virtual! We're one month away from the un-conference and are opening the virtual ticket booth for this free event, with optional add-ons for event t-shirts and an on-site social in Emeryville after the event. Bring your topics and prepare to discuss! https://dtraceconf24.eventbrite.com

@brauner @corbet @kernellogger @jann I'm doing most of my new code outside kernel and doing mostly fixes and reviews inside kernel ATM. The current cycle gives me opportunity to downscale and upscale my own contribution, not a lot but just enough.

Putting the release cycle too tight would make at first the life more difficult for independent kernel maintainers like me.

I've also noticed that the current window is great for big features, which need to fly for few weeks to get somewhat decent release quality. I might put a feature to Linus in the first PR and notice some actual problem at rc5/rc6. This would be a risk factor too.