Re: [gentoo-dev] udev and /usr

[Joost Roeleveld]

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:
>
> http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.x
> 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