Gentoo Archives: gentoo-dev

From: Joost Roeleveld <joost@××××××××.org>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] udev and /usr
Date: Thu, 15 Sep 2011 16:05:41
Message-Id: 3639422.QgOtQNiHae@eve
In Reply to: Re: [gentoo-dev] udev and /usr by Zac Medico
On Thursday, September 15, 2011 08:07:35 AM Zac Medico wrote:
> On 09/15/2011 07:33 AM, Joost Roeleveld wrote: > > The use for an initrd/initramfs/... will create an additional layer of > > complexity a lot of us users are not really waiting for, especially as > > we are not seeing any issues with our current systems. > > Like it or not, it's the simplest possible solution if you want separate > /usr. The plan is to provide a minimal initramfs that won't contain any > modules, so it won't have to be rebuilt for each kernel. See the "/usr > vs. initramfs redux" thread: > > > ml
Zac, Thank you for your response, however, I do have a few questions about this. Where will this default initramfs actually need to be placed? Also, how will we be able to deal with situations where this script fails? If Gentoo does decide to follow the initramfs-route, why not simply implement /etc/init.d/localmount in the initramfs? Why require users to figure out which filesystems are needed for udev? Also, I was actually hoping for a reply to the rest of my email as well, especially the idea for splitting udev into 2 seperate processes. What I'm thinking off would be the following in pseudo-code: --- process 1 --- while(wait_for_event()) { kevent* pkEvent = NULL; if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting { action_event = process_kernel_event(pkEvent); if (action_event != NULL) { put_action_event(pkEvent); } } } ------ --- process 2 --- while(wait_for_event()) { aevent* paEvent = NULL; if(get_waiting_action_event(paEvent)) // returns true if an event was waiting { process_action_event(paEvent); } } ------- In "human" that would be: The kernel puts events in the new-dev-event-queue that process 1 picks up. process 1 creates the /dev-entrie(s) and, if there is an action to be taken, puts the action in the new-action-event-queue. Process 2 will then pick up this action from the new-action-event-queue and will process this. If, as a side-effect, of the action processed by process 2, a new device appears for the kernel, the kernel will simply put a corresponding event in the new-dev-event-queue. I don't see why this option would be ignored. Especially as the simpler process 1 should be smaller and as such less likely to contain bugs and any action that needs to be taken can be done manually to test why something isn't working correctly if the boot-process, for whatever reason, fails. I'm not a good enough developer to do build this myself, but I am willing to try this. All I'm asking for is the help and advice of more experienced developers with the design and implementation. If someone can explain to me why my idea won't work, please let me know. If someone actually has some ideas on how to implement it, I would really appreciate it. My current idea is to try to split the 2 parts out of udev and have it use the same configuration files. Many thanks, Joost


Subject Author
Re: [gentoo-dev] udev and /usr Zac Medico <zmedico@g.o>