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 1R4HFi-0003ha-Ns for garchives@archives.gentoo.org; Thu, 15 Sep 2011 19:05:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9786321C254; Thu, 15 Sep 2011 19:05:29 +0000 (UTC) Received: from mail-wy0-f180.google.com (mail-wy0-f180.google.com [74.125.82.180]) by pigeon.gentoo.org (Postfix) with ESMTP id 5624021C060 for ; Thu, 15 Sep 2011 19:04:37 +0000 (UTC) Received: by wyj26 with SMTP id 26so3829010wyj.11 for ; Thu, 15 Sep 2011 12:04:37 -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=Z0suK+skdD+yKxv7jYVYWzoZg0NXiRvq+iBRMvvAMXU=; b=MSN1Yon2wxE8ceE1yH5z+zRME60AA+nvajSxbP2dzS1Ck/owrWH2XOeq1aVa73VTdk kOqAydY0eb/+ulKO5Yks+iXuhS4EZC/E5cmhPPktVf6Fsoxrq4g0LElZrk116uIpNpud iSCguKEwzeCcKJ3Wd2z6xIoPrJe+kxLhnxBd4= 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.187.201 with SMTP id y51mr1443569wem.95.1316113477379; Thu, 15 Sep 2011 12:04:37 -0700 (PDT) Received: by 10.216.38.140 with HTTP; Thu, 15 Sep 2011 12:04:37 -0700 (PDT) In-Reply-To: <201109151859.54274.michaelkintzios@gmail.com> References: <20110912150248.GB3599@acm.acm> <3318888.8i9Hhk9ViB@eve> <2463763.HTbTZix19o@pc> <201109151859.54274.michaelkintzios@gmail.com> Date: Thu, 15 Sep 2011 15:04:37 -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: 6bf24b380b6b38bc99c051d052dd27fa On Thu, Sep 15, 2011 at 1:59 PM, Mick wrote: > On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote: >> On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote: >> > 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've read it there. Thanks for doing this. > > Thanks Joost for posting in the dev list and for explaining your proposed > approach there. =C2=A0I've just read your thread in the dev list: > > http://thread.gmane.org/gmane.linux.gentoo.devel/72969 > > > Zac's response helped me understand better what the Gentoo devs have been > suggesting here: > > http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264e= f.xml > > and it does make sense - their version of initramfs-'lite'. > > From what I understand: > > 1. =C2=A0The minimal initramfs will only need to be built once (and rarel= y rebuilt > thereafter). =C2=A0This removes one of my fears and it was a main objecti= on for me > - I would hate to have to rebuild initramfs every time I roll a new kerne= l, or > libs and what not of fs happen to be udpated, etc. In my experience, it takes more time to build the kernel than it takes to rebuild the initramfs. And if you choose to use dracut, the process is automatic (you always call dracut with the same options, unless you suddenly add LVM or something similar). I didn't use an initramfs for my first years using Gentoo. Since I started to use media-gfx/splashutils a couple of years ago, every time I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do the same, but with plymouth and systemd using dracut. It's just part of the process of getting a new kernel. > 2. If initramfs fails, then Zac says it will drop you into a minimal shel= l, so > we should still be able to recover/troubleshoot/reboot from there. >From the last response in the -dev list (from Rich Freeman): =E2=80=9CIt should be noted that the alternative is to use a more full-featured initramfs like dracut, which will also be updated to support mounting /usr (it already parses /etc/fstab to remount root anyway). ... Note that dracut does drop you to a shell if it fails (this is configurable), but by default this shell is dash, not bash. No doubt it would work fine either way, but bash is likely to be a little slower. I don't think RAM use is likely to be a problem - it should be completely de-allocated before init runs.=E2=80=9D > The only drawback is the 2 minutes it will take a user the first time thi= s > change is introduced to build the initramfs and change the kernel line in > grub.conf. =C2=A0I am warming up to this proposal because it seems to me = that it > will end up being less painful that I originally thought. Reading the homepages of the projects involved always helps to better understand the possible outcome of using the new technologies. Perhaps you should take a look at dracut: Maybe a complete initramfs solution will convince you, especially if an initramfs will be needed anyway. > However, I still see it as a workaround to a more elegant solution, which= as > Joost and others suggest would involve separating udev's probing for devi= ces > with the rules running of scripts for them. Maybe that's the more elegant solution. Certainly it will take a lot more effort, in the sense that somebody has to implement, test and debug said solution. I sincerely wish them good luck. 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