From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R4DGG-0007LE-R9 for garchives@archives.gentoo.org; Thu, 15 Sep 2011 14:49:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A643321C1B3; Thu, 15 Sep 2011 14:49:45 +0000 (UTC) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) by pigeon.gentoo.org (Postfix) with ESMTP id 3E7FD21C07C for ; Thu, 15 Sep 2011 14:48:54 +0000 (UTC) Received: from [212.54.42.136] (helo=smtp5.tb.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1R4DFF-0001Og-Gw for gentoo-user@lists.gentoo.org; Thu, 15 Sep 2011 16:48:53 +0200 Received: from 5ed027a1.cm-7-1a.dynamic.ziggo.nl ([94.208.39.161] helo=data.antarean.org) by smtp5.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1R4DFB-00040D-17 for gentoo-user@lists.gentoo.org; Thu, 15 Sep 2011 16:48:49 +0200 Received: from localhost (localhost [127.0.0.1]) by data.antarean.org (Postfix) with ESMTP id 7F4B0DAB for ; Thu, 15 Sep 2011 16:48:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at antarean.org Received: from data.antarean.org ([127.0.0.1]) by localhost (data.antarean.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmt9iEZWAPDE for ; Thu, 15 Sep 2011 16:48:57 +0200 (CEST) Received: from eve.localnet (eve.lan.antarean.org [10.20.13.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPS id B0320635 for ; Thu, 15 Sep 2011 16:48:57 +0200 (CEST) From: Joost Roeleveld To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev + /usr Date: Thu, 15 Sep 2011 16:48:45 +0200 Message-ID: <3318888.8i9Hhk9ViB@eve> User-Agent: KMail/4.7.1 (Linux/2.6.36-gentoo-r5; KDE/4.7.1; x86_64; ; ) In-Reply-To: References: <20110912150248.GB3599@acm.acm> <1900171.RYZackCgQ3@eve> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-ZiggoSMTP-MailScanner-Information: Please contact the ISP for more information X-ZiggoSMTP-MailScanner-ID: 1R4DFB-00040D-17 X-ZiggoSMTP-MailScanner: Found to be clean X-ZiggoSMTP-MailScanner-SpamCheck: geen spam, SpamAssassin (niet cached, score=0.708, vereist 5, BAYES_05 -0.50, KHOP_DYNAMIC 0.73, RDNS_DYNAMIC 0.98, RP_MATCHES_RCVD -0.50) X-ZiggoSMTP-MailScanner-From: joost@antarean.org X-Spam-Status: No X-Archives-Salt: X-Archives-Hash: d4096db14fbc5e5a3c6f7ccb9df500d4 On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote: > On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld 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. > > 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.) I agree he is wrong about the solution as well. I have actually just posted my idea to the gentoo-dev list to see how the developers actually feel about possible splitting udev into 2 parts. I'm not a good enough programmer to do this myself. But if anyone who can code and who also agrees with me that my idea for a solution is actually a good idea, please let me know and lets see how far we can get with implementing this solution. -- Joost