On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld <[email protected]> wrote:
>> I'm not entirely convinced this is the case, because it feels like
>> some situations like network devices (nbd, iSCSI) or loopback would
>> require userland tools to bring up once networking is up.
>
> Yes, but the kernel-events referencing those devices won't appear untill after
> the networking is brought up.
> The scripts that "udev" starts are run *after* a device-event is created. If
> the device itself has not been spotted by the kernel (for instance, the
> networking doesn't exist yet), the event won't be triggered yet.
>
> This situation does not require udev to start all these tools when network-
> devices appear.
>
> I hope the following would make my thoughts a bit clearer:
>
> 1) kernel boots
>
> 2) kernel detects network device and places "network-device-event" in the
> queue
>
> 3) further things happen and kernel places relevant events in the queue (some
> other events may also already be in the queue before step 2)
>
> 4) udev starts and starts processing the queue
>
> 5) For each event, udev creates the corresponding device-entry and places
> action-entries in a queue
>
> 6) system-init-scripts mount all local filesystems
>
> 7) udev-actions starts (I made up this name)
>
> 8) udev-actions processes all the entries in the action-queue
>
> From step 4, udev will keep processing further events it gets, which means
> that if any action taken by "udev-actions" causes further devices to become
> available, "udev" will create the device-entries and place the action in the
> action-queue.
So, if I read this correctly, there are two classes of processing
events. kernel events and scripted actions. Here's rough pseudocode
describing what I think you're saying. (Or perhaps what I'm hoping
you're saying)
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting
{
process_kernel_event(pkEvent);
}
else
{
aevent* pAction = NULL;
if(get_waiting_action(pAction)) // Returns true if there's an
action waiting.
{
process_action(pAction);
}
}
}
So, udev processes one event at a time, and always processes kernel
events with a higher priority than resulting scripts. This makes a
certain amount of sense; an action could launch, e.g. nbdclient, which
would cause a new kernel event to get queued.
> If anyone has a setup where /usr can not be mounted easily, it won't work
> currently either and a init* would be necessary anyway.
> (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers,.... hosting /usr
> or other required filesystems)
I don't see how this is relevant to actually fixing udev. (See below)
> But anyone with a currently working environment should be able to expect a
> currently working environment. If it fails to boot with only updating
> versions, it's a regression. And one of the worst kinds of all.
I agree that the direction udev is going is a regression. There aren't
very many people active in this thread who would disagree with that
point. So let's just drop it and focus on what a good, general
solution would look like. (And anyone who says something amounting to
'status quo' for udev needs another explanation of why the udev
developer sees the current scenario as broken. And he's right; the
current scenario is architecturally unsound. I just think he's wrong
about the solution.)
--
:wq
