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 1RiqDa-0006sc-CV for garchives@archives.gentoo.org; Thu, 05 Jan 2012 16:31:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9604921C0AF; Thu, 5 Jan 2012 16:30:52 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 33CC821C026 for ; Thu, 5 Jan 2012 16:29:52 +0000 (UTC) Received: from mail-wi0-f181.google.com ([209.85.212.181]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RiqCQ-000Rqv-Nn for gentoo-user@lists.gentoo.org; Thu, 05 Jan 2012 23:29:54 +0700 Received: by wibhq2 with SMTP id hq2so568655wib.40 for ; Thu, 05 Jan 2012 08:29:48 -0800 (PST) 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.180.75.7 with SMTP id y7mr6160297wiv.2.1325780988105; Thu, 05 Jan 2012 08:29:48 -0800 (PST) Received: by 10.223.78.208 with HTTP; Thu, 5 Jan 2012 08:29:47 -0800 (PST) Received: by 10.223.78.208 with HTTP; Thu, 5 Jan 2012 08:29:47 -0800 (PST) In-Reply-To: <20120105140801.1737ce43@rohan.example.com> References: <20111115062115.GA3262@waltdnes.org> <20111121104724.GC7461@waltdnes.org> <20111201194544.GD4455@waltdnes.org> <20120103100445.GD1961@waltdnes.org> <20120103123209.GB2410@nicolas-desktop> <20120103131346.GC2410@nicolas-desktop> <20120103143120.GF2410@nicolas-desktop> <20120103221555.22c778a3@digimed.co.uk> <4F038C23.5030708@gmail.com> <4F04E1B4.3050901@gmail.com> <20120105020254.455da0df@rohan.example.com> <4F0551AC.2070608@coolmail.se> <20120105094312.02a82a80@rohan.example.com> <4F055C93.4070601@coolmail.se> <20120105140801.1737ce43@rohan.example.com> Date: Thu, 5 Jan 2012 23:29:47 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3 From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=f46d0434bf56d8948704b5ca70f5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: 56cc295d-22fa-408a-954a-f93e43855de4 X-Archives-Hash: 24392204ef37cf162321cb2b583d720f --f46d0434bf56d8948704b5ca70f5 Content-Type: text/plain; charset=UTF-8 On Jan 5, 2012 7:10 PM, "Alan McKinnon" wrote: > > On Thu, 05 Jan 2012 09:17:23 +0100 > pk wrote: > > > On 2012-01-05 08:43, Alan McKinnon wrote: > > > > > I fiddle around a lot with the hardware on those and udev deals with > > > that nicely considering udev is designed to deal with that nicely. > > > > I confess to being quite ignorant when it comes to what magic udev > > does behind the scenes but what makes it different to any other device > > manager (well, I don't know any other than mdev but...)? I.e. what > > technical problem(s) does udev solve that no other device manager > > can't? What is the technical need for something else than a device > > file under /dev that can be used to communicate with the kernel? > > > > What I mean is: If you say "... considering udev is designed to deal > > with that..." you seem to indicate that you know what it does and why > > it does what it does... and henceforth the technical reason why the > > rearrangements of the file system hierarchy is necessary... > > I don't claim any special deep knowledge of these things, but a > superficial glance over the packages tells you a lot. udev is designed > to deal with any realistic device needs on modern systems - it's the > kitchen sink. > > mdev has a much narrower scope where things are considerably more > static. > > As for re-arranging the fs layout, I think it was Canek in the last > thread that gave an excellent example of why this is needed. When > devices hotplug, or need to become active early on in the boot process, > they need to run code that can be located almost anywhere. It wouldn't > be fun trying to get a wireless keyboard going when it's start-up > script needs to get into /usr/lib/firmware and /usr isn't mounted yet. > > The example was something along the lines of a machine that has no > physical keyboard or a port for one, it uses a bluetooth keyboard. But > the main file systems are encrypted using a key that's on a smartcard. > To decrypt and mount the filesystems, the drivers for keyboard, > bluetooth and smart card, plus all firmware, needs to be loaded first. > This is actually not all that far-fetched, and it's a classic bootstrap > problem first solved in the 60s. It much more complex now than it was > then but the principles behind the solution are much the same. > > I do agree with collapsing the executable code in /usr into /, or > having /usr on the root partition. A separate /usr/{,s}bin is pretty > pointless and was never done for safety or maintenance reasons. It was > done way way way back when disks were small and a convenient hack was > to keep the OS on the boot device and user apps somewhere else on > bigger but slower storage (which often was remote). > > If /usr is local, what really is the point of having it separate > from /? Have you ever found a Linux system in any condition that could > not start just because the stuff in /usr was available? I haven't. > > Even the split between bin and sbin is arbitrary. It's only there so > that users can take sbin out of PATH and not have the screen cluttered > with endless junk when they tab-tab. It makes much more sense to me to > just have one single bin and lib location and shove everything into it. > > What I do object to is any possible idea that an initramfs will be > *required* regardless. I know this isn't on the table just yet, but > it's a very small amount of creep before it is. > > > > > > Becoming rather lazy in my old age is getting to be a factor too > > > > Ho hum... so "you lazy old fart" is true then? ;-) > > Dunno about lazy old fart, but splog (snarky pedantic lazy old git) > definitely is. I think we decided that Neil is the lazy old fart :-) > After some soul-searching (yes, I still have one despite learning from BOFH), I think I'll agree with Alan... with some caveats. I have less resistance to requiring /usr to be part of /. The way I see it, I can still do some bind mount black magic to provide a minimal /usr for booting yet isolating the 'real' /usr to prevent it messing up the rootfs. As to udev, I still think it's an overkill for a static server environment. With virtualization, I can *guarantee* that the (virtual) hardware environment will never change. For these environments, I much prefer mdev to udev. Finally, regarding initramfs, I wholly agree. Don't force me to use one. A server is already a complex system, and adding complexity won't end up pretty. Rgds, --f46d0434bf56d8948704b5ca70f5 Content-Type: text/html; charset=UTF-8


On Jan 5, 2012 7:10 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Thu, 05 Jan 2012 09:17:23 +0100
> pk <peterk2@coolmail.se> wrote:
>
> > On 2012-01-05 08:43, Alan McKinnon wrote:
> >
> > > I fiddle around a lot with the hardware on those and udev deals with
> > > that nicely considering udev is designed to deal with that nicely.
> >
> > I confess to being quite ignorant when it comes to what magic udev
> > does behind the scenes but what makes it different to any other device
> > manager (well, I don't know any other than mdev but...)? I.e. what
> > technical problem(s) does udev solve that no other device manager
> > can't? What is the technical need for something else than a device
> > file under /dev that can be used to communicate with the kernel?
> >
> > What I mean is: If you say "... considering udev is designed to deal
> > with that..." you seem to indicate that you know what it does and why
> > it does what it does... and henceforth the technical reason why the
> > rearrangements of the file system hierarchy is necessary...
>
> I don't claim any special deep knowledge of these things, but a
> superficial glance over the packages tells you a lot. udev is designed
> to deal with any realistic device needs on modern systems - it's the
> kitchen sink.
>
> mdev has a much narrower scope where things are considerably more
> static.
>
> As for re-arranging the fs layout, I think it was Canek in the last
> thread that gave an excellent example of why this is needed. When
> devices hotplug, or need to become active early on in the boot process,
> they need to run code that can be located almost anywhere. It wouldn't
> be fun trying to get a wireless keyboard going when it's start-up
> script needs to get into /usr/lib/firmware and /usr isn't mounted yet.
>
> The example was something along the lines of a machine that has no
> physical keyboard or a port for one, it uses a bluetooth keyboard. But
> the main file systems are encrypted using a key that's on a smartcard.
> To decrypt and mount the filesystems, the drivers for keyboard,
> bluetooth and smart card, plus all firmware, needs to be loaded first.
> This is actually not all that far-fetched, and it's a classic bootstrap
> problem first solved in the 60s. It much more complex now than it was
> then but the principles behind the solution are much the same.
>
> I do agree with collapsing the executable code in /usr into /, or
> having /usr on the root partition. A separate /usr/{,s}bin is pretty
> pointless and was never done for safety or maintenance reasons. It was
> done way way way back when disks were small and a convenient hack was
> to keep the OS on the boot device and user apps somewhere else on
> bigger but slower storage (which often was remote).
>
> If /usr is local, what really is the point of having it separate
> from /? Have you ever found a Linux system in any condition that could
> not start just because the stuff in /usr was available? I haven't.
>
> Even the split between bin and sbin is arbitrary. It's only there so
> that users can take sbin out of PATH and not have the screen cluttered
> with endless junk when they tab-tab. It makes much more sense to me to
> just have one single bin and lib location and shove everything into it.
>
> What I do object to is any possible idea that an initramfs will be
> *required* regardless. I know this isn't on the table just yet, but
> it's a very small amount of creep before it is.
>
> >
> > > Becoming rather lazy in my old age is getting to be a factor too
> >
> > Ho hum... so "you lazy old fart" is true then? ;-)
>
> Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
> definitely is. I think we decided that Neil is the lazy old fart :-)
>

After some soul-searching (yes, I still have one despite learning from BOFH), I think I'll agree with Alan... with some caveats.

I have less resistance to requiring /usr to be part of /. The way I see it, I can still do some bind mount black magic to provide a minimal /usr for booting yet isolating the 'real' /usr to prevent it messing up the rootfs.

As to udev, I still think it's an overkill for a static server environment. With virtualization, I can *guarantee* that the (virtual) hardware environment will never change. For these environments, I much prefer mdev to udev.

Finally, regarding initramfs, I wholly agree. Don't force me to use one. A server is already a complex system, and adding complexity won't end up pretty.

Rgds,

--f46d0434bf56d8948704b5ca70f5--