Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Date: Wed, 14 Mar 2012 08:39:20 +0000 (UTC)
Joshua Kinard posted on Tue, 13 Mar 2012 20:16:10 -0400 as excerpted:

> On 03/13/2012 07:54, James Broadhead wrote:
> 
>> I believe that the Art of Unix Programming* says that /usr was the
>> result of the original UNIX 4MB hard disk becoming full, and that they
>> chose /usr to mount a second one. Every definition since then has been
>> an attempt to justify preserving the split.
> 
> Sounds like how a lot of UNIXy things came into being.  This is why I
> think /usr should be merged back into /, not the other way around. 
> Although, both approaches essentially achieve the same effect in the
> end, once you move /etc and a few other bits, then point the kernel at
> "/usr".

I've seen it pointed out that in initr* based systems anyway, the "new" 
rootfs is effectively taking the role the old initrd tmproot did, it's 
only there in a bootstrapping role, no "running system" content at all, 
except that instead of using pivot_root or whatever to get off it once 
the system early bootstrap is done, it remains the mountpoint used by 
everything else on the running system.

That's rootfs's only modern role, according to these folks, providing the 
mountpoints for everything else.

And with an assumed initr* based setup, it all "just works".  Rootfs can 
in fact be entirely virtual, tmpfs or squashfs or whatever, setup only in 
the initr*, with only a few minimal early-boot config files, the modules 
necessary to boot the rest of the system, etc, as content, and those 
quickly over-mounted with the "real" system -- note that /usr/etc can be 
bind-mounted over the boot-time-stub /etc too, so literally, post-initr*, 
the ONLY part of rootfs operationally visible is the mountpoints used by 
everything else.

THAT is why they're moving /bin, /sbin and /lib to /usr rather than the 
other direction.  rootfs will be ONLY a mountpoint, with even /etc/ being 
bind-mounted from /usr/etc, and all system data unified on /usr, 
including /etc.

Viewed from that perspective, the direction of the "unification", 
everything formerly on rootfs moving to /usr, so rootfs' only function is 
providing the mountpoints for everything else, has a certain logic to 
it...

And they don't care about non-initr* based systems any more than they 
care about non-Linux systems or for that matter, non-systemd Linux 
systems.  That's outside their operational universe.  Other people are 
welcome to continue working with "legacy" systems if they want, but Linux-
only, systemd-based, initr*-based systems are the only thing they're 
interested in supporting, themselves.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



Replies:
Re: Re: Let's redesign the entire filesystem!
-- Joshua Kinard
References:
newsitem: unmasking udev-181
-- William Hubbs
Re: newsitem: unmasking udev-181
-- Rich Freeman
Re: Re: newsitem: unmasking udev-181
-- Luca Barbato
Re: Re: newsitem: unmasking udev-181
-- William Hubbs
Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
-- Joshua Kinard
Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
-- James Broadhead
Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
-- Joshua Kinard
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Next by thread:
Re: Re: Let's redesign the entire filesystem!
Previous by date:
Re: newsitem: unmasking udev-181
Next by date:
Re: New eclass proposal: chromium.eclass


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.