Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/14/2012 05:00 AM, James Cloos wrote: >> "MS" == Marc Schiffbauer writes: > > MS> IIRC usr = unified system resources (not an abbrev. for "user") > > Nope. It is in fact for user. > > Before sysv created /home, bsd used /usr for user dirs. > > /usr/bin et all came later. Anyway, "unified system resources" makes a great retro-active acronym, don't you think? What's in a name? -- Thanks, Zac
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
> "MS" == Marc Schiffbauer writes: MS> IIRC usr = unified system resources (not an abbrev. for "user") Nope. It is in fact for user. Before sysv created /home, bsd used /usr for user dirs. /usr/bin et all came later. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On Tue, Mar 13, 2012 at 8:20 PM, Joshua Kinard wrote: > The trend now seems to be to modularize everything these days, even stuff > like the core disk drivers, then build those core modules into an initramfs > that the kernel cherrypicks from at boot. That's the perception, anyways, > and one which I don't really get. Well, on most distros the kernel is just another package that is the same on every box. If you want one kernel for every PC, then it needs to support every piece of hardware in existence. So, either it is highly modular, or it is going to suck up a ton of RAM. The solution is a one-size-fits-all kernel, combined with a one-size-fits-all initramfs. For Gentoo where people build their own kernels, it doesn't make as much sense. Rich
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/13/2012 01:17, Luca Barbato wrote: > > So you need need a smaller udev that is completely self contained and make > sure anything needed for the key rules works. I wonder if the pci-ids cannot > stay somewhere in /etc or /lib > > lu I think gregkh is already on record as saying that the pci-ids file is going to go into /usr and stay there. The errors I got weren't from that, though, it was the init scripts trying to find udevadm, and then not finding libkmod, which was likely installed into /usr/lib64. I guess I don't run a "standard" Linux system anymore. I build a fairly monolithic kernel that contains device drivers for all the hardware in the machine needed to get it up and running, while miscellaneous modules (like CIFS or the Happy MEal quad ethernet card) are modulues. My MIPS systems all run pure monolithic, completely lacking module support entirely. The trend now seems to be to modularize everything these days, even stuff like the core disk drivers, then build those core modules into an initramfs that the kernel cherrypicks from at boot. That's the perception, anyways, and one which I don't really get. Correct me if I'm wrong... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/13/2012 07:54, James Broadhead wrote: > On 13 March 2012 01:22, Joshua Kinard wrote: >> We should be working to getting rid of /usr and bring it all back into /, >> then create temporary /usr symlinks to point programs in the right >> direction. After all, /usr was originally for user data, not system data, >> until someone cooked up /home (I don't know the full exact history here, so >> feel free to correct me). >> > > 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". -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 13 March 2012 14:41, Marc Schiffbauer wrote: > Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard: > [...] >> After all, /usr was originally for user data, not system data, >> until someone cooked up /home (I don't know the full exact history here, so >> feel free to correct me). > > IIRC usr = unified system resources (not an abbrev. for "user") > > -Marc > -- > 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 Again, backwards justification for a directory name that was already in place.
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard: [...] > After all, /usr was originally for user data, not system data, > until someone cooked up /home (I don't know the full exact history here, so > feel free to correct me). IIRC usr = unified system resources (not an abbrev. for "user") -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/03/12 11:14 PM, Joshua Kinard wrote: > On 03/12/2012 22:33, Ian Stakenvicius wrote: > >> >> On 2012-03-12, at 9:22 PM, Joshua Kinard >> wrote: >> >>> >>> And yes, I've already tested out udev-181 on a VM with a >>> separate /usr. With devtmpfs, the system fully boots just >>> fine, no initramfs needed. Guess what the only piece of >>> software to mess up is? Udev. I largely think it's a timing >>> issue in OpenRC, however, because /usr DOES get mounted fairly >>> quickly, but not before udevd starts. But udevd does restart >>> itself and everything looks to work fine. If you aren't >>> watching the terminal, you wouldn't even notice the failures. >>> >> >> >> THANK YOU for testing this -- I could not forsee a reason, back >> when this process started, as to why openrc couldn't mount /usr >> before udev started. since devtmpfs should provide the source >> devnode anyways. It's good to have a (near) proof of that. >> >> Ian > > Yeah, I think it's an easy fix either in openrc or in an initscript > somewhere. I changed nothing except my kernel (was missing > devtmpfs -- it's not under Filesystems!), uninstalled > module-init-tools, and installed kmod + udev-181. Then rolled back > the snapshot once I had the results. Ah, right; kmod.. Tthere's pressure for that one to move to /usr too, isn't there mgorny? ok, nvm. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk9fTXIACgkQAJxUfCtlWe3RQQD8DIr8mZ773vIqhIxf5ERYWo8E ZkfDgAUlUDF7hcDiuUIA/1amWFFZcVu36V6vikq4HGF0we43YYMVLW6b96SblGzN =dKid -END PGP SIGNATURE-
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 13 March 2012 01:22, Joshua Kinard wrote: > We should be working to getting rid of /usr and bring it all back into /, > then create temporary /usr symlinks to point programs in the right > direction. After all, /usr was originally for user data, not system data, > until someone cooked up /home (I don't know the full exact history here, so > feel free to correct me). > 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. * On reflection, I may have read this elsewhere.
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On Mon, 12 Mar 2012 21:22:26 -0400 Joshua Kinard wrote: > On a somewhat sarcastic note, why don't we just deprecate /usr and > move everything back to /? Isn't that, largely, what is being > accomplished here? Solaris at least keeps some kernel stuff in / off > of /stand (I believe). Linux, after this /usr thing is fully > complete, about the only thing left in / that is of any value will > be /etc. Kernels were moved into /boot ages ago. A bit like stali? http://sta.li/ Or is that still too complicated? :) jer
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 3/12/12 8:53 PM, Robin H. Johnson wrote: On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote: Yeah, I think it's an easy fix either in openrc or in an initscript somewhere. I changed nothing except my kernel (was missing devtmpfs -- it's not under Filesystems!), uninstalled module-init-tools, and installed kmod + udev-181. Then rolled back the snapshot once I had the results. When udev is linked against a library in /usr, this is not going to work anymore, because udev won't start at all. So you need need a smaller udev that is completely self contained and make sure anything needed for the key rules works. I wonder if the pci-ids cannot stay somewhere in /etc or /lib lu
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote: > Yeah, I think it's an easy fix either in openrc or in an initscript > somewhere. I changed nothing except my kernel (was missing devtmpfs -- it's > not under Filesystems!), uninstalled module-init-tools, and installed kmod + > udev-181. Then rolled back the snapshot once I had the results. When udev is linked against a library in /usr, this is not going to work anymore, because udev won't start at all. On many simple setups, yes, it's not going actually break much in my testing on pure OpenRC. udev starts in the sysinit runlevel, and /usr would normally only become available later, in the boot runlevel, when localmount runs... Consider this potential boot order: sysinit/sysfs sysinit/udev (fails without sysfs) boot/modules (after udev, so udev rules work on modprobe) boot/hwclock (needs rtc modules on some systems) boot/fsck (after devices are available) boot/root (after fsck) boot/localmount (after fsck) udev before modules is fairly critical for some hardware, so that it gets configured properly. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 2012-03-12, at 9:22 PM, Joshua Kinard wrote: > > And yes, I've already tested out udev-181 on a VM with a > separate /usr. With devtmpfs, the system fully boots just fine, no > initramfs needed. Guess what the only piece of software to mess up is? > Udev. I largely think it's a timing issue in OpenRC, however, because /usr > DOES get mounted fairly quickly, but not before udevd starts. But udevd > does restart itself and everything looks to work fine. If you aren't > watching the terminal, you wouldn't even notice the failures. > THANK YOU for testing this -- I could not forsee a reason, back when this process started, as to why openrc couldn't mount /usr before udev started. since devtmpfs should provide the source devnode anyways. It's good to have a (near) proof of that. Ian
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/12/2012 21:37, Kent Fredric wrote: > On 13 March 2012 14:22, Joshua Kinard wrote: >> I thought this up on a whim, it hasn't been tested nor vetted. It's largely >> meant as a joke, but also to provoke discussion on the current filesystem >> design and the direction we're getting pulled in with Fedora's declaration >> that separate /usr is broken. I don't think it is and I don't find their >> argument very convincing, and probably never will. >> > > Why don't we just quit with this linux nonsense and all switch to Mac, > after all, it just works! > > > > =p The problem with that, is, that the system wouldn't boot without /itunes being available, so you can't partition that one off :P -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 13 March 2012 14:22, Joshua Kinard wrote: > I thought this up on a whim, it hasn't been tested nor vetted. It's largely > meant as a joke, but also to provoke discussion on the current filesystem > design and the direction we're getting pulled in with Fedora's declaration > that separate /usr is broken. I don't think it is and I don't find their > argument very convincing, and probably never will. > Why don't we just quit with this linux nonsense and all switch to Mac, after all, it just works! =p -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
[gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/11/2012 13:33, William Hubbs wrote: > I highly discourage moving more things to /. If you google for things > like, "case for usr merge", "understanding bin split", etc, you will > find much information that is very enlightening about the /usr merge and > the reasons for the /bin, /lib, /sbin -> /usr/* split. > > I'll start another thread about this farely soon, but for now I'll say > that even though Fedora is a strong advocate of the /usr merge, it > didn't start there. Solaris started this 15 years ago, and I think it > would be a good thing for gentoo to implement the /usr merge at some > point to make us more compatible with other unixes. Another thing to add > is that it appears that at least Fedora and Debian are doing this. On a somewhat sarcastic note, why don't we just deprecate /usr and move everything back to /? Isn't that, largely, what is being accomplished here? Solaris at least keeps some kernel stuff in / off of /stand (I believe). Linux, after this /usr thing is fully complete, about the only thing left in / that is of any value will be /etc. Kernels were moved into /boot ages ago. I mean, what really is / in the literal sense? It's the first filesystem that the kernel mounts. If you put everything into /usr, including the init scripts and /etc, create a few stub mount points for /var, /tmp, etc (assuming those are separate partitions), then told the kernel that /usr is /, what's the real difference? So I think Fedora's approach, while copying existing behavior from Solaris, is partially broken in this regard. We should be working to getting rid of /usr and bring it all back into /, then create temporary /usr symlinks to point programs in the right direction. After all, /usr was originally for user data, not system data, until someone cooked up /home (I don't know the full exact history here, so feel free to correct me). Heck, why not redesign the original root filesystem layout while we're at it? / - Root. /boot - Kernels, bootloader. /apps - Installed, non-system critical applications. Merges /bin, /sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and all of its multilib variants. /core - System-critical apps needed to get the system into a MINIMAL, usable state (core device detection, mounting disks, etc) /conf - System configuration data. /dev - Device nodes. /home - User stuff. /data - Variable data. /var's new name. /tmp - System-wide temp dir. /virt - virtual filesystems (proc, sys, ramfs). /svcs - Data dir for services (Apache, LDAP, FTP, etc). /ext - holds mount points for external devices (merges /mnt & /media). /root - Superuser's /home. From that, for the new proposed directories: /apps/sys/bin - System binaries. Only non-critical, system-wide binaries go here. /apps/sys/lib - Like /apps/sys/bin above. Except this can also be duplicated for multilib (lib32, lib64, lib128, etc). /apps/std/bin - Standard program binaries for all non-system, non-critical binaries. /apps/std/lib - Like /apps/std/bin above. Ditto for multilib. /apps/local - If on a stand-alone system, this is a symlink to /apps/std. otherwise, this holds a bin/lib folder that is only for apps installed locally, while /apps/std might be a network mount that holds apps common to multiple systems of the same/similar type of install. /core/bin - Critical system, binaries needed to get the system into a minimally-usable state. Predominantly occupied by various filesystem tools. /core/lib - Libraries, usually static, to support /core/bin. Can be multilib, but a system should have a single ABI that can successfully boot the userland components of the system. /core/inf - Holds minimal information to identify and locate boot-critical devices, typically in the form of a small database of some design, but which can be parsed with no additional dependencies. /core/init- Home of your init system of choice, including all the information needed for various run levels, etc. Its sub-layout is dependent on the particular init system that is installed. /conf - Basically a rename of /etc. The "etc" name doesn't convey any useful information to a user anymore about its true purpose. /conf, however, does. Files stored here will largely be comprised of text files that configure various system services. Like /etc, it's sub-layout will probably be a complete, unrestrained mess. /virt - Everyone loves virtual filesystems. When there was just /proc, everything was alright. Then /sys comes along, and now we've polluted the / namespace with two virtua