one idea for integration, which would be a lot more generic than patching-in a specific tool, is to *somehow* provide static binaries to the kernel that can run in their own "bare root", and tagged for some use-cases.
**So, use-cases?**
The obvious one is some form of early output handler that encompasses the boot logs too. This could not only handle *showing* boot logs according to semantics customizable by the distribution. Not only can it handle boot logs, but with proper userspace smarts, also hand-off to the next graphical thing, or do anything... e.g. progress bars encompassing the full boot?
Another use-case would be another "tag" for hooking up to kernel panics. While panics are "major system ending events", I believe it should be fine to allow a handler to *try* to make it more useful for end-users in some form. What if `systemd-bsod` was able to hook itself into that system and *also* handle kernel panics? That would be a neat way to tie the idea up!
**And *somehow*?**
My first guess would be a `cpio` file provided in a certain way to the kernel would be useful, and a useful mechanism to add other "smarts" to the boot process.
Anyways, just some thoughts I had a while back. Take this for inspiration.
samueldr /
npub17n…2af8d
2024-08-24 20:48:09
in reply to nevent1q…uaf9
Author Public Key
npub17nwchcnz2densynkeu2dztxufgpftzuhzznczmvjuakejcdcgl7s92af8dPublished at
2024-08-24 20:48:09Event JSON
{
"id": "455bdc1977e3df298a960bd56bb4df67bf5575c884592d7256feac312405c36e",
"pubkey": "f4dd8be2625373381276cf14d12cdc4a02958b9710a7816d92e76d9961b847fd",
"created_at": 1724525289,
"kind": 1,
"tags": [
[
"p",
"aeb58459b764d3eb4ecdc304a27e311f7d7cdaafa3471b2959dc22600ed3dc90"
],
[
"e",
"2fa92a0f82b401e188eb314dd4d7af39ad4163e9ed110d24af19b82ac760177d",
"",
"reply",
"aeb58459b764d3eb4ecdc304a27e311f7d7cdaafa3471b2959dc22600ed3dc90"
],
[
"e",
"3a552d444893ff5791667ee4d48ad70ca2f9b974b73c5dbff652464a314ec18f",
"",
"root",
"aeb58459b764d3eb4ecdc304a27e311f7d7cdaafa3471b2959dc22600ed3dc90"
],
[
"p",
"5a99c001a61c7604e620f02b8345fac4413b535f86aa1c009a0f217b756c8252"
],
[
"p",
"2ba475a1340ebd9f8ec27d9173cd47f78bde6f58760f13854303ba6bd6f3a930"
],
[
"proxy",
"https://ap.samueldr.com/objects/3a9d2a2e-aa64-4d6d-8385-b5a705d39ff0",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://ap.samueldr.com/objects/3a9d2a2e-aa64-4d6d-8385-b5a705d39ff0",
"pink.momostr"
],
[
"-"
]
],
"content": "one idea for integration, which would be a lot more generic than patching-in a specific tool, is to *somehow* provide static binaries to the kernel that can run in their own \"bare root\", and tagged for some use-cases.\r\n\r\n**So, use-cases?**\r\n\r\nThe obvious one is some form of early output handler that encompasses the boot logs too. This could not only handle *showing* boot logs according to semantics customizable by the distribution. Not only can it handle boot logs, but with proper userspace smarts, also hand-off to the next graphical thing, or do anything... e.g. progress bars encompassing the full boot?\r\n\r\nAnother use-case would be another \"tag\" for hooking up to kernel panics. While panics are \"major system ending events\", I believe it should be fine to allow a handler to *try* to make it more useful for end-users in some form. What if `systemd-bsod` was able to hook itself into that system and *also* handle kernel panics? That would be a neat way to tie the idea up!\r\n\r\n\r\n**And *somehow*?**\r\n\r\nMy first guess would be a `cpio` file provided in a certain way to the kernel would be useful, and a useful mechanism to add other \"smarts\" to the boot process.\r\n\r\nAnyways, just some thoughts I had a while back. Take this for inspiration.",
"sig": "cd7fcfb9b78ef933f94e3e900a2ee2b0b46564d9419dddb5f3fc6e853107bf815448c35ec3c3fd7e9b57873fb38a097749a92826e463888ecbd3c4ba2b229365"
}