Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Joost Roeleveld <joost@...>
Subject: Re: udev and /usr
Date: Thu, 15 Sep 2011 18:04:56 +0200
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


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 ---
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was 
    action_event = process_kernel_event(pkEvent);
    if (action_event != NULL)


--- process 2 ---
  aevent* paEvent = NULL;
  if(get_waiting_action_event(paEvent)) // returns true if an event was 

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,


Re: udev and /usr
-- Zac Medico
udev and /usr
-- Joost Roeleveld
Re: udev and /usr
-- Zac Medico
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: udev and /usr
Next by thread:
Re: udev and /usr
Previous by date:
Re: udev and /usr
Next by date:
Re: udev and /usr

Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.