-
-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Boot refactor #138
Merged
Merged
[RFC] Boot refactor #138
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Everything else Finit does related to parsing the incoming arguments is in conf.c, so it makes sense for this block to also reside there.
Upcoming external plugin support means that even though there are no internal plugins that depend on this hook, there might be external ones.
Traditionally, Finit has setup _some_ filesystems that are Nice To Have (tm), using options that do the Right Thing (tm). On the one hand, this is very convenient for users that don't necessarily know what a reasonable mode= value is for /tmp etc. (pun intended). It also means that mountpoints can be created if they don't exist. On the other hand it means that all users are forced to submit to the choices made by Finit. Also, different filesystems where spread out at many different points in `main()`, meaning that the fact that `/proc` was available at a given hook point did not imply that `/sys` was, for example. Instead, defer _all_ filesystem setup to the user by simply calling `mount -a`. We then ship an example `fstab` that shows how to re-create the old behavior.
Instead of heuristically trying to determine the correct hotplug daemon to use (mdev/udev), defer to the user to specify it in the configuration. Same goes for the built-in watchdog.
No other hook is treated in this fashion, so it seems silly to single out poor HOOK_BASEFS_UP.
The contents of /etc/finit.conf and friends could potentially change after mounting /etc/fstab. If, for example, /etc was to be re-mounted from ro to rw using an overlay filesystem, we want any user changes to the configuration to take effect.
We want plugins to be able to register themselves at the banner hook point, but that requires that we have actually loaded them before then.
This way, the default behavior stays the same, but users can opt out by disabling the plugin.
No feedback, just looks awesome, great work on this! ❤️ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This series refactors the core of Finit with the goal of giving the user more ability to tailor the system to their liking. As a result, it cuts many lines from
main()
, making it easier to get an overview of the boot process. The big stuff:Generic cleanup/moving around of dead/misplaced code.
Remove all automatic mounting of different filesystems at different points in the boot process; just call out to
mount -na
and let the user decide on the exact set of filesystems and options.Move
udev
/mdev
stuff out to a plugin that can be disabled and replaced with whatever the user needs (or doesn't need).I would really like some feedback on the series as it is now, so that we can integrate these changes before going further.