Arch Linux

Thread for this: http://bbs.archlinux.org/viewtopic.php?pid=547593

+1
This would make hooking in stuff like Fbsplash and similar much more clean and easy. Looking forward for this... :)

I don't think I like this. It's a little TOO complicated.

The fbsplash overriding was expected to be done via functions in functions.d - if we need more things split into functions, that would be a better approach.

But this scheme seems like overkill. Now, *some* modularity wouldn't be a bad thing, but I don't want to turn all of sysinit into individual modules that people can disable willy-nilly like this

Well, currently hooking in things like splash into rc.sysinit and rc.shutdown is very tricky. Have a look at http://aur.archlinux.org/packages/initscripts-extras-fbsplash/initscripts-extras-fbsplash/fbsplash.inithooks
We need to check against various stat_busy message texts there to start/control/stop the daemon. Additionally I needed to duplicate the CONSOLEFONT stuff to move it at the end of the boot because it destroys the splash screen.

Hmm this does look messy, but I'm still not convinced turning rc.sysinit into 30 different files is the way to go here. It looks more like this is all a solution because the splash-functions-arch.sh file is overly complex. I'm sure it could be simplified - just looking through all this malarky makes me think "holy hell this is way too complicated just for a graphical progress bar"

> It looks more like this is all a solution because the splash-functions-arch.sh file is overly complex. I'm sure it could be simplified - just looking through all this malarky makes me think "holy hell this is way too complicated just for a graphical progress bar"
When talking about a 'simple progress bar' I would agee, bit it isn't a 'simple progress bar', it is Fbsplash ! All the script does is hooking into splash-functions.sh from upstream which provides a sophisticated event framework with things like a message log within the splash screen which can be toggled using the keyboard, drawing icons for services starting/stopping/failing, event hooks for scripts provided by the themes and such. The additional complexity was introduced for some kind of translation or abstraction, because there are no real services to hook in on ArchLinux, just rc scripts containing any number of stat_{busy,done,fail}. The rest are some options I added - freedom of art ;) - and some workarounds. I like ArchLinux because it's simple and that means it's even simple to get complex and broken stuff to run on it. (... like some bloated broken DEs, but thats a different story ;)
On the one hand I understand your concerns about people fiddling with sysinit modules but on the other hand the only thing they have to do by now to mess up sysint is to go into the wiki, search for 'faster boot' and start editing rc.sysinit. So why not give them more freedom ?

I would actually posit that it's _less_ freedom, considering that they would then have to edit umpteen files rather than just one.

I see that this would be useful to fbsplash, but that's it - it's only useful to fbsplash. In all other cases, it's unneeded complexity.

I'd like to see some middle ground here, perhaps by simply adding some sort of "event hooks" into the existing rc.sysinit that would help out fbsplash, but also not overcomplicate the boot process (one the the things the reviews always seem to praise about Arch is the simplistic boot process)

Hmm... the bug report was about simplifying modifying sysinit and Fbsplash is just an additional reason to take this into account. The point is that rc.sysinit contains the actual sysinit stuff *and* the framework hardwired together. So if someone modifies it he actually forks initscripts. (Thats exactly what Thomas Bächler is hating so much.)
When it comes to Fbsplash we would need to add event hooks at the following points AFAIKS:
in rc.sysinit:
- After proc is mounted and before the first stat_busy to be able to parse the kernel cmdline, mount a tmpfs and cache any messages/fails until the daemon can be started.
- Right after starting udevd to be able to trigger and settle the tty and graphics stuff and start up the daemon early.
- After all udev uevents are triggered and settled to get the keyboard event device.
in rc.shutdown:
- When sending sigterm to be able to restart the daemon.
- When sending sigkill for the same reason.
- Before remounting the root fs readonly to be able to save some info if needed.
- Before the actual power off or reboot to be able to shutdown the splash with a nice fadeout effect.

One option to think about is the way debian does these things in their initramfs. They have lists of "hooks" similar to we do, but done at different times. i.e. "pre_mount=somescript; post_mount=anotherscript; pre_procmount=something" etc etc etc

Hmm... we would need to find names for all services started in any scripts in /etc/rc.d ... [sorry, have to go away now]

Well, i don't think we need every single step broken apart. Debian is able to do it in about 4 or 5 stages. This also goes for the SIM concept. I think it's far far too granular, but if it were done in, say, 5 or 6 distinct steps, then it might be cleaner.

Yep... I think I overdid the modularization. Using just a few, coarser modules should make the SIM approach more amenable.

To put it in terms of "what would make me happy":

* Everything on by default. I don't like the list in rc.conf - perhaps just some way to disable or replace existing modules? Or just use everything in a given directory?

* Less modules, coarser grained

Lets see where we get with that. I would like to get something like this into the initscripts, but the existing implementation seems to go a little crazy :)

Yep... I think I overdid the modularization. Using just a few, coarser modules should make the SIM approach more amenable.

Darn... Sorry for the last post. I reloaded the browser window, which created a copy of my last comment.

@phrakture: Did a quick (final hopefully) cleaning on the Fbsplash scripts. Maybe you like them a bit more now, if not, simply don't use them. :) Allowing someone else to implement a better solution was actually one of the reasons why I moved the scripts out of the fbsplash package into a separate one.

@phrakture: Now I did some 'heavy refactoring' on the scripts. It's still the some malarkey, but maybe more readable now. ^^

I think this is superseded by Thomas' hooks system implemented in git, is it not?

@Aaron: I guess, the answers is yes, at least in some way. Hooks looks good (initscripts-2009.11-1)