So I thought, and discarded and thought some more. Now I want anyone willing to comment on my thoughts.
My proposal is a user-land based filesystem that is specifically built to work with sysvinit to give it more functionality without changing it. You want a standard sysvinit Unix boot just don't pass a parameter to the kernel commandline, no problemo. However, with it enabled you would "theoretically" get the following.
1) Basic cached ram overlay. This could possibly be used to replace our readahead scripts for disk caching. The more immediate need is a temporary ram file-system to allow system processes to write logs, status, pipes to before we have had a chance to verify disk integrity. This should get us the ability to provide nice X based gui tools for first boot, system recovery, and possibly encryption unlocking.
2) Better init logging. With /var writable ( at-least in ram ) we can start syslog nice and early.
Just those two things give us a nicer gui boot screen and possibly cut the time of launching X twice off our boot sequence. Now we go one step further.
3) We use the abstraction layer to manipulate the startup scripts that init sees in /etc/rcX.d .
This would require
A) Netlink support. Do we or don't we have a network interface. If we don't then automatically remove all network
dependant services from init. If Network comes up later in the process and init is still running ( we know that
because we can keep track of /var/lock/subsys ) the filesystem re-adds them later in the process.
B) General dependencies. Like I mentioned we can keep track of what has started using /var/lock/subsys or
/var/run. If Something fails remove the dependent scripts out of the way so init doesn't try to start them.
C) Ability to maximize IO throughput. Well this is just a thought. Right now we see one of the major bottlenecks
in our init process as overloading the IO subsystem. With an intelligent read only overlay we could do basic
metrics and possibly wait a second longer to start the next process knowing it will shorten the time to launch
the next service by 2 seconds. I have no proof this will work, but after looking at those bootchart graphs
enough some crazy ideas cross your mind.
4) After the init process is done, the filesystem flushes itself to the lower layer writables disks and disappears.
First, sorry if this is wrapped horribly. I am using gmail and it doesn't lend itself to formatting long mails like this.
Second, Let's talk about it. Like I said this just came to my mind as something that doesn't exist, and might possibly help us build a better system around what we already have.
Jon
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
