From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B0A851381F3 for ; Wed, 19 Dec 2012 15:04:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 078BF21C08C; Wed, 19 Dec 2012 15:04:38 +0000 (UTC) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8290F21C06B for ; Wed, 19 Dec 2012 15:03:27 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id un3so2031829obb.7 for ; Wed, 19 Dec 2012 07:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Olu+Q4BokNiDsTeXdSuUA1RPLcLZYTFOCy6NZ1hFv6w=; b=nHzzSpEx/e0blQK1YjKmJz43YbY06yrb5fyjRS9ZwRga8ZXGkGJG3+eIs3cs8LpODG sibYek+K9I7aF7d3n3g94acHZLvMHEQBAhn0CBPlpp1bywuapM8L4i78xVuviJzkFTbg gt8JHgbGqfpCq7PUnmi8Qu8NdKF9OjkLcQJ90Ri/DuQ4MD/KGtCBdBn/vKuLHYz+xmfr YcbdZeb7qCIL2K9bqfDqeMUwjqjJ7SxMfrScN8wo0y7uhGV4xDZqAWJQTzdouYANNaWQ Kaf8ACkHZkJKzEgOS00mRY1sFcwm/pyMHygSjwbFKZA+ydIwHnGjmbDFu8pFbKtjy3Sr n99g== 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.60.10.133 with SMTP id i5mr4925068oeb.24.1355929406689; Wed, 19 Dec 2012 07:03:26 -0800 (PST) Received: by 10.76.20.243 with HTTP; Wed, 19 Dec 2012 07:03:26 -0800 (PST) In-Reply-To: <20121219112607.5f1b8f31@khamul.example.com> References: <50CB1942.3020900@gmail.com> <50CB4A3C.1030109@gmail.com> <50CB5406.7040404@gmail.com> <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.com> <20121218163332.7956f31a@khamul.example.com> <20121219112607.5f1b8f31@khamul.example.com> Date: Wed, 19 Dec 2012 10:03:26 -0500 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: b749a621-9a89-4f56-ae32-f5d817264a5d X-Archives-Hash: abb2f8bfba8b81f5cff2f188a4601f45 On Wed, Dec 19, 2012 at 4:26 AM, Alan McKinnon wrote: > On Tue, 18 Dec 2012 17:55:16 -0500 > Michael Mol wrote: > >> On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon >> wrote: >> > On Tue, 18 Dec 2012 09:08:53 -0500 >> > Michael Mol wrote: [snip] >> > #2 already has a solution, it's called an init*. Other solutions >> > exist but none are as elegant as a throwaway temporary filesystem >> > in RAM. >> >> I find virtually nothing elegant about a temporary filesystem in RAM. >> It duplicates code that already exists on the system, and it >> represents and additional maintenance step in system upgrades. It >> seems almost a given that if someone is keeping multiple kernel images >> on a system, they're not updating the initr* for each when binaries >> that would be found in each are upgraded or rebuilt. > > You could level the same criticism at boot loaders... > > The also duplicate functionality in the main system they launch (albeit > read-only at least in legacy grub) in the fs drivers, are only used > briefly at boot-time and have to be maintained. True, the bootloader > doesn't contain a *copy* of the main system files which is where the > parallel breaks down. Bootloaders tend to be updated in a targeted or atomic fashion. This remains true even as they become more and more like full operating systems. > > init* may well suck, but they suck less than any other possible > solution. I disagree. I think defining boot stages, and fixing cross-stage dependency errors, is a far better solution. > And they come with one more benefit - the community has > agreed on how they work so they form a standard of sorts > >> >> In Debian, Ubuntu and others, this is handled by a post-install hook >> where the initr* image is rebuilt. To me, this honestly feels like a >> hack. In something like Gentoo, I'd rather see package placement >> driven by whether or not it will be needed to get all mount points >> mounted. If that means i18n databases under something like /boot/data, >> that seems reasonable. To me, the only cases where initr* feels like >> the right solution are things like netboot or booting from read-only >> media. > > Let's not forget the prime reason why init* exists - so that binary > distros can boot and still have all kernel modules required at launch > time compiled as modules. Another valid use case. > > Bootstrap code and operation is ugly, always has been and always will > be. It also tends to be inflexible unless you use a slipstreaming > technique (my invented description of how init* works). I still think > the solution is elegant given the real-world requirements imposed on > systems. And I still think that, outside of scenarios where workarounds don't exist, it's an ugly hack and a cop-out. -- :wq