On 7.1.2015 19:55, Michal Koutný wrote: > During designing the new service manager I've come up against > chicken-egg problem. My approach was motivated by minimizing amount of > data in boot device (the one read by GRUB) and number of tasks started > by kernel (GRUB modules). This lead me to idea of splitting the > "basic" initalization and "user" initialization. > > Currently, it would mean moving logger task from GRUB module to initrd > and starting it during "basic" initialization and the rest of current > tasks would be started during the "user" initialization. Eventually, > this could be exploited to have the root filesystem separated from > initrd. Actually, I found this topic already mentioned in HelenOS > tickets [1], similarly to Linux early user space. > > This separation would require changing the root filesystem (I think > that implementing this in the VFS would be the most effective > (concerning required changes)). Consequently, device manager would > need an ability to reload/update its drivers list. > > What do you think? Am I wrong about something or unaware of some > horrendous consequences?
So there appear to be two issues here. The first issue is to make the system work even without initially having logger available. I think it will currently hang if logger is not there. The other issue is that you think that you need to change the root filesystem. Why, in your opinion, is this necessary? Surely, we should probably implement this eventually, but why not simply mount the initrd as root and the prospective persistent filesystem under e.g. /root (to bring some confusion to all the people who expect something else under /root) or /r? The devman and such would have to be told about the new driver repository (and taught to make use of this information). As for changing the initrd root for a persistent root, it seems possible after some effort. Note that Jiri Zarevucky is working on a VFS2 that may make this potentially easier or just different. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
