On 5/17/2012 4:37 AM, James Hunt wrote:
Sounds like both systems are performing initialisation to me. And as we know, there is symmetry between what happens in the initramfs and what then has to happen again in the main system. By using Upstart, we get one tool to do that job without duplication of code.
Sure, but upstart is performing a lot more initialization. The only initialization the initramfs needs is to bring up the root device, which is handled mostly by udev rules, and thus, already using common event driven code.
Upstart provides a "udev bridge" that allows arbitrary jobs to react to udev events without having to install udev rules in one of the 3 udev locations (although I guess that's really potentially 5 if you include the initramfs locations (but exclude /run)). For the cases where you aren't modifying devices, it makes working with udev much simpler.
Yes, I know upstart can build more layers on top of the udev events, but what I don't understand is why you would want to. What I am looking for is a specific example of something you want upstart to do above the udev rules that both needs done while the system is fully up and running, and also needs done to find the root fs.
The code for mountall is admittedly more complex than simply calling 'mount', but it has the following advantages: - it actually performs error checking (unlike the initramfs mount code).
And what would you do in the event of an error? If the fs is so damaged that it can't be mounted, then about all you can do is report the error to the user and halt or drop them to the busybox shell. So I guess what you are saying is that you want a pretty plymouth error message instead of plain console text?
- it provides user feedback on the operations via Plymouth. - it runs fsck and provides feedback to the user via Plymouth.
So you also want to put all of the fscks and their dependencies in the initramfs? Or it would only do this for non root filesystems? Why would we want to do this in the initramfs instead of when the real init runs?
AFAIK, plymouth is not currently in the initramfs because it was decided that adding it and the rather sizable graphics drivers that it depends on would bloat the initramfs too much, so why do we now want to not only add all of that, but upstart and mountall as well?
So far the only advantage I'm seeing is that we can make a rare class of error messages and the luks password prompt look pretty. I can see the argument for that, but does it really require upstart and mountall too?
That's not actually what we're talking about here - the upstreams are moving tooling currently in / to /usr. We might be able to work around this, but it sounds like it will become increasingly difficult to do so.
What upstream doesn't support the normal configure switches to set the install directory, and that mountall depends on?
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
