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 1R4DP4-00087G-SZ for garchives@archives.gentoo.org; Thu, 15 Sep 2011 14:59:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 45F5421C240; Thu, 15 Sep 2011 14:58:44 +0000 (UTC) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id A8EAE21C203 for ; Thu, 15 Sep 2011 14:57:28 +0000 (UTC) Received: by wyg36 with SMTP id 36so3323136wyg.40 for ; Thu, 15 Sep 2011 07:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=+uYFUQc/9GmIZ2oT83o098cVPrm5rWM3GqSePv0zL4U=; b=d0JgvFT2ML8t7YsMf6jnoyeHgTOd7rD+FZuPDyMmGN9OqJluT6FXOyNA5nmdjhZ40p 8nE07AeWD6BR0tylJPStnYAAMtvMSFghbZFN+Eah0BFfyYUQafVBUhGeuPbGyKLV4s9G 851BGLbt/TMz52KDZa83eTQxPL6B4mR2ReuxM= 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 Received: by 10.216.229.221 with SMTP id h71mr4055weq.80.1316098647494; Thu, 15 Sep 2011 07:57:27 -0700 (PDT) Received: by 10.216.38.140 with HTTP; Thu, 15 Sep 2011 07:57:27 -0700 (PDT) In-Reply-To: References: <20110912150248.GB3599@acm.acm> <2056931.seTjzgOPrt@eve> <1900171.RYZackCgQ3@eve> Date: Thu, 15 Sep 2011 10:57:27 -0400 Message-ID: Subject: Re: [gentoo-user] udev + /usr From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 53ddd389ebfa66ce92e33f0a5c8fe18b On Thu, Sep 15, 2011 at 10:32 AM, Michael Mol wrote: > On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld wr= ote: >>> 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 netwo= rk- >> 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 th= e >> 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 place= s >> 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 mea= ns >> that if any action taken by "udev-actions" causes further devices to bec= ome >> 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()) > { > =C2=A0kevent* pkEvent =3D NULL; > =C2=A0if(get_waiting_kernel_event(pkEvent)) // returns true if an event w= as waiting > =C2=A0{ > =C2=A0 =C2=A0process_kernel_event(pkEvent); > =C2=A0} > =C2=A0else > =C2=A0{ > =C2=A0 =C2=A0aevent* pAction =3D NULL; > =C2=A0 =C2=A0if(get_waiting_action(pAction)) // Returns true if there's a= n > action waiting. > =C2=A0 =C2=A0{ > =C2=A0 =C2=A0 =C2=A0process_action(pAction); > =C2=A0 =C2=A0} > =C2=A0} > } > > 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 wor= k >> 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.) Let me throw my own guess of how they came out with the corrent proposed solution. I repeat: is my own guess: I am not the one calling the shots, so maybe I'm completely wrong. As many of you guys said, there are ways of solving the problem without requiring an initramfs. Note that if you decide to use an initramfs, every use case works: You can have a practically empty /, throw everything in /usr, and have /usr in another partition, maybe even an encrypted remote NFS share. With an initramfs you can have a separate /var, you can even have a separated /etc, mounted even by NFS too. You can do pretty much whatever you want, because you have a full userspace *the moment you boot*. Bluetooth, network, LVM, crypto-filesystems: Everything is available from the instant zero. >From that perspective, the problem then is trying to support the initramfs-less setups. Putting myself in the shoes of the developers, the smart solution is to simply force an initramfs. KISS is to force an initramfs, because it solves everything. The Gentoo devs are working in a minimal initramfs that works for most "normal" usecases. Everything else will be handled by dracut or genkernel. An initramfs is not an initrd. And is not a binary blob coming who knows from where; with dracut, your initramfs is simply a subset of your normal installation, and can be as simple (just mount /usr) or as complicated (LVM+crypto+network+NFS+whatever) as you want. Of course you can solve it differently, for example splitting udev as Joost proposes. But then is more code to maintain, and the number of possible setups is suddenly the double it was before. It. Is. Not. KISS. It's a lot like the CUPS/lprng situation we discussed before. CUPS can do anything that lprng does, so it makes no sense to keep support for lprng. It's the same: with an initramfs you will be able to do anything, so it will make no sense to keep supporting initramfs-less systems. That's how I see it. Regards. --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico