Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
Date: Thu, 15 Mar 2012 12:31:29
In Reply to: Re: [gentoo-dev] Re: Let's redesign the entire filesystem! by Joshua Kinard
1 On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard <kumba@g.o> wrote:
2 > This does lead me to wonder if a light-weight udev could exist that lacks
3 > half or more of the functionality of the current udev.  I'll be honest, I've
4 > only edited my udev rules file once, and that was only when I installed a
5 > Sun Happy Meal quad ethernet card in which all four ports utilize the same
6 > MAC address and udev doesn't handle this very gracefully (if I had Solaris,
7 > I could edit the card's firmware and change this setting).
9 You know - I had a similar issue, but with a pair of PL2303 USB RS232
10 interfaces. That makes me wonder if there is a possible way to
11 enhance udev to better handle situations where devices have no unique
12 ID and thus tend to be difficult to access consistently across
13 reboots. In my case I had to hack a rule so that I got a symlink if
14 the device was in a specific USB slot. Use case is controlling tuners
15 for mythtv.
17 No doubt a simpler 80% solution could be created for udev, and likely
18 it would be easier to cut down on its dependencies as a result.
19 However, the other 20% of users will still need the more complete
20 solution. Big distros that want to support lots of hardware with a
21 one-size-fits-all configuration will just deploy that complete
22 solution everywhere, which means that the only people maintaining the
23 simple solution would be people who like to tailor each system.
25 For most of the more enterprise-y OS providers (ie the ones with money
26 to pay devs), one-size-fits-all is a lot more sustainable. You won't
27 find an edition of MS Windows that works only on PCs without scanners
28 and sound but uses 50MB less RAM, for example.
30 Sure, we don't have the same constraints as the enterprise-y distros,
31 but we do have the constraint that if we want to do things differently
32 we will spend a lot of time patching what we could otherwise simply
33 reuse as-is.
35 I don't think that split filesystem installs are going away anytime
36 soon. In fact, when btrfs is finally mature we might see them
37 blossum. Using subvolumes you could have more granular snapshotting
38 and mount options, while still maintaining a shared disk space pool
39 (with granular quotas). If everything the distro is likely to mangle
40 is in a few subvolumes you can reverts snapshots on those without
41 losing changes in other subvolumes if you ran in production before
42 deciding to revert. That gets you a lot more flexibility than a
43 single snapshot on root - especially in terms of recovery time (you
44 can still copy files between snapshots if you only snapshotted root -
45 in fact with reflinks this is very fast).
47 Rich