Skip to content

Conversation

@KarlK90
Copy link
Member

@KarlK90 KarlK90 commented Dec 4, 2025

No description provided.

src/cmdline.rs Outdated

#[test]
fn test_rsinit_bind() {
let cmdline = "root=/dev/root rsinit.bind=/lib/modules\n";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the new line?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, the test fails if it isn't added. I haven't looked deeply into the parsing logic though.

src/cmdline.rs Outdated
pub nfsroot: Option<String>,
pub init: String,
pub cleanup: bool,
pub bind_mount: Option<String>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this allow for multiple bind_mount= parameters?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, but I can add them if you want

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added, please have a look.

@KarlK90 KarlK90 force-pushed the feature/bind-mount-modules branch from 5e190af to 8f15fd9 Compare December 4, 2025 14:29
@KarlK90 KarlK90 force-pushed the feature/bind-mount-modules branch from 8f15fd9 to 8afa205 Compare December 4, 2025 14:30
@michaelolbrich
Copy link
Member

So this is not something I want in the main rsinit binary. I see the use-case for something like that and I think we should have a "development" init for this and other features.
I'm not sure yet if I want to turn the whole thing into a workspace and put this stuff in a separate crate there, or if a separate repository makes more sense. What do you think?

The goal would be to create one "development" init that can cover most development use-cases.

"init" => options.init = ensure_value(key, value)?.into(),
"rsinit.bind" => options
.bind_mount
.push(ensure_value(key, value)?.to_string()),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this will obviously not work like this from a separate crate. What would be a good way in rust to make the parser extendable? I'm looking for something where a custom function would be called for any unknown command-line option.

For the bind-mount case in particular, I think it makes sense to configure the mounts in the initramfs (some kind of config file?) since that's where the directories that are mounted come from anyways.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I had a stab at implementing callbacks at various stages of the rsinit binary, which allows implementing the functionality of this PR e.g. parsing the necessary command line options and running custom commands e.g. after the rootfs was setup. I opened a RFC PR for that #22

@KarlK90 KarlK90 mentioned this pull request Dec 4, 2025
@KarlK90
Copy link
Member Author

KarlK90 commented Dec 4, 2025

So this is not something I want in the main rsinit binary. I see the use-case for something like that and I think we should have a "development" init for this and other features.

Agreed, separating this from the main rsinit implementation is a good idea.

I'm not sure yet if I want to turn the whole thing into a workspace and put this stuff in a >separate crate there, or if a separate repository makes more sense. What do you think?

I'm for the workspace solution. I don't see the need for another repository (yet) at this point.

The goal would be to create one "development" init that can cover most development use-cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants