On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld <[email protected]> wrote: > On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote: >> 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); >> } >> } >> } > > This is, sort-of, what I feel should happen. But currently, in pseudo-code, > the following seems to happen: > while(wait_for_event()) > { > kevent* pkEvent = NULL; > if(get_waiting_kernel_event(pkEvent)) // returns true if an event was > waiting { > process_kernel_event(pkEvent); > } > } > > I would prefer to see 2 seperate processes: > > --- 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); > } > } > ------- > >> 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. > > Yes, except that udev ONLY handles kernel-events and doesn't process any > "actions" itself. > These are placed on a seperate queue for a seperate process.
The problem with this is that you now need to manage synchronization between the kernel event processor and the action processor, which is actually more complicated than keeping them together in a single-threaded, single-process scenario. -- :wq
