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 1R1lj6-0000jl-Op for garchives@archives.gentoo.org; Thu, 08 Sep 2011 21:01:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8508F21C2A9; Thu, 8 Sep 2011 21:01:13 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 1235021C417 for ; Thu, 8 Sep 2011 20:57:40 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1374717bkb.40 for ; Thu, 08 Sep 2011 13:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=rDhASW1+fBjDZyfpPcFoHB4pynEEq03+x8es6ao68FQ=; b=FTwUfx+1FwBhUjceBRSULmRVyg1TAlTYMNuvQQAZvsGOBoRaIxdIKjkTzeW4OmUVDU /oEyIFaa6kkJXCNXYxh1t9ulxTpgP3lcIoLRxUCOlaRnBKZRuwEvqGg9H+dTyTNhXsmJ WcjRd/qU2ZK+ck3oXh3yoqCorwwztmNshA1hw= 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.204.157.1 with SMTP id z1mr858433bkw.277.1315515460050; Thu, 08 Sep 2011 13:57:40 -0700 (PDT) Received: by 10.204.155.79 with HTTP; Thu, 8 Sep 2011 13:57:39 -0700 (PDT) In-Reply-To: References: <201108191109.34984.michaelkintzios@gmail.com> <2799076.QhjHdal4hI@pc> <2110889.rUh24Q481G@pc> Date: Thu, 8 Sep 2011 16:57:39 -0400 Message-ID: Subject: Re: [gentoo-user] /dev/sda* missing at boot From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 7379d765fc2d1e02a8c9bf3c0babb15f On Thu, Sep 8, 2011 at 4:03 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > On Thu, Sep 8, 2011 at 3:37 PM, Michael Mol wrote: >> On Thu, Sep 8, 2011 at 3:00 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: >>> Sorry you read that way; I keep trying to explain why I don't find a >>> separated /usr a necessity and why I don't think an initramfs is such >>> a big problem. >> >> The rhythmic baseline of your explanation is "and you can use an >> initramfs for that." I haven't seen much in argument for why initramfs >> isn't a problem apart from your expectation that the *kernel* will >> eventually require it, and dracut theoretically solve the problem of >> updating initrd. (Which sounds nice, but it's yet another moving part >> in the system, and another point of failure.) > > No, I think you haven't been reading carefully enough. Again: > > 1. In 2011, we need a dynamic /dev tree. I'm not going to argue why. I'll go ahead and conflate "dynamic /dev tree" with things like alternate names for network interfaces, and then I can agree with you there. (I don't put up with this ethN, sitN, tunN BS. Give me an interface name that says what it's for. I need udev for that, though.) > 2. udev, successor of devfs, which was successor of the classical /dev > tree, after years of design and development iterations, solves the > problem. It's not perfect, but I think that is as close as it could > be, for the problem it tries to solve, and with the feature set it > has. I'll give a pass on this one; I don't know enough about how it operates to be very informed. > 3. udev needs either an initramfs, because it needs an early user > space, or a /usr inside /. First, it sounds like we're conflating /usr with "user space". User space is any executing space in the system, but outside the kernel. /usr is just one of several traditional mountpoints in UNIX-like systems. Second, why can't we say, "anything that needs to be operated by udev needs its binaries in /bin or /sbin"? As I said, I thought that was the whole *point* of having those distinct from paths under /usr; anything you needed in order to perform online system recovery would be in one of those two folders. Anything needed to perform online system recovery ought to be nearly sufficient to bootstrap the system. (The only mountpoint exception I can think of is /etc) Yes, this may mean modifying many more packages, but that's what having a clean system architecture is about. Unless I'm misunderstanding sysadmin history, that would seem to be the Correct solution, and would be the strongest broad solution. > From this 3 points, I make my conclusion: keep up with the changes, or > code an alternative (that includes using something like mdev). >> I thought the primary reason we had >> /{,s}bin and /usr/{,s}bin was to differentiate between system-vital >> programs and other programs. > > That enters perflectly in my other solution: code an alternative. That > includes changing (or trying to) udev. "Changing udev" wasn't on the table earlier. > >>> That people don't like the answer doesn't mean is not true. >> >> There's also no solid evidence that it's true, either. > > Prove me wrong, or find the code that proves me wrong. If it's that > important to you, do it. My whole point is that it's easier (and in > the long term more beneficial) to roll with the changes. What's important to me is clarity of the situation and understanding the Whys and trying to understand the logic (and illogical aspects) of the scenario. I'm just trying to be clear on everything here. As I said, I can deal, it's just a pain. As has been mentioned, there are other architectures which will have a harder time of it. That's their problem. Still, if the Kernel is deciding that udev is the be-all hotplug manager, though, and udev is hanging edge architectures like MIPS out to dry, then we'll be lucky if a common, familiar and compatible environment will continue to be available on MIPS. Maybe they'll fall back to a static /dev. Maybe they'll come up with something good to replace udev. Or maybe manufacturers using MIPS will use something other than Linux, such as QNX, and MIPS will be a much less hackable platform than it once was. >> I remember when >> sysfs came about. Linux Journal's diff -u column described it as a >> herculean effort accomplishing something the majority of kernel devs >> thought impossible or not worth the time. I rather like sysfs, but at >> one time, it was the thing very few people thought was in the possible >> set of solutions. > > I don't see the connection. If someone actually goes and writes the > code for an alternative to udev (or /usr inside /, or an initramfs), > then it enters my second alternative. See my note above about modifying udev not being clearly on the table earlier. In an environment where a single dev is responsible for something, foreign patches aren't often welcome. >> People are beginning to consider alternatives, but you've shot them >> down without offering improvements, suggesting adjustments or even >> pointing out specific flaws. As a result, you come across as something >> akin to a fanboy with your mind already made up, which just seems >> *bizarre*. > > I don't really care if people mind me a fanboi: I know I'm not. I'm > old enoguh to be a fanold, though. Heh. Fair enough. > > Seriously, maybe I'm not communicating my point clearly. The only > alternative mentioned (I think: please correct me if I'm wrong) is > mdev... which I didn't shoot down, I just mentioned that I don't think > will solve the problem. And if you have followed the development of > Linux as I have, then you know it is a *really* hard problem, and that > udev is the result of many man-hours of thinking, designing and > implementing. That's why I don't give to much hope to a project I have > never heard about. I'd be _very_ careful about that mentality. If you've been following Linux as long as I have (and I honestly think you've been following it longer; I only started in 1998), you'll remember that Linux was once an upstart nobody'd heard of. I'm not trying to draw a direct analogy between Linux and mdev, I'm just trying to illustrate that it's problematic to ignore small projects because it's assume the big ones have already thought something through. I've personally tended to find that big projects and organizations tend to evolve a set of assumptions (we'll call it groupthink) and don't challenge it often enough. > That doesn't mean I'm not mistaken, of course. Sure. And I'm not trying to say you're necessarily *wrong*, I'm just trying to break down and poke the assumptions and arguments I'm hearing. >>> Sometimes the devs do stupid things; but most of the times they really >>> think and come to a solution. And the affected users usually just see >>> how that solution affects them in the short term, instead of trying to >>> see the big picture and how affects the whole distribution, the >>> community, and the technological path that Linux is following. >> >> For being irritated that people aren't seeing it, you haven't been >> clarifying it much. > > When did I say I was being irritated? I'm only trying to express my POV. Hm. I may have read too much emotion into the text. My bad. >> That much is appreciated, but you didn't say *why* you doubt that'll >> be the solution. Downvotes aren't debate, nor are they discussion. >> They're expressions of dissatisfaction. > > Why should I be dissatisfied? The development of Linux goes exactly in > the direction *I* want, I don't complain about any of the required > changes discussed. > > Why I doubt it I answered some paragraphs above. Understood, points taken, some addressed. > >>>> As for me, this will be a royal inconvenience, and may require the >>>> rebuilding of my primary machine. Still, I can deal. It'll mean >>>> learning how to build initramfs*, how to make sure it contains the >>>> needed tools, and probably a half-dozen other things I didn't even see >>>> coming when I set up this box last fall. >>> >>> I compile my own kernels (no genkernel for me). I don't use modules >>> (except for the stupid scsi_wait_scan), and I didn't used an initramfs >>> until I started using systemd. The arguments for using it convinced >>> me, and I made the switch in all my machines. >>> >>> I don't see why it would require to "rebuild" your primary machine, >>> but I don't know your configuration. I know that any sane >>> configuration would only require to install dracut and modify a line >>> in grub. Maybe a kernel rebuild. >> >> My / isn't large enough to hold /usr. > > I don't understand. You said you were to try building an initramfs, > and if that's the case, then you can keep /usr separated. > > If you will put /usr in / (and hence rebuild your system), then why > you said you would learn how to built an initramfs? I fully expected building an initramfs with a bunch of userland binaries to be a PITA. If drago is as simple as you describe it, then perhaps not. At the original point when I indicated I'd need to rebuild my machine, that was under the assumption I wouldn't be able to figure out the initramfs. >>> Apparently. But is not "grossly" unnecessary: udev need it, and udev >>> solves a kinda complicated problem. Maybe mdev can solve it in a >>> simpler way. >>> >>> But again, I doubt it. >> >> One question: Why? Are there specific technical reasons to your >> doubts, or is it simply confidence that the devs are more likely to >> have made a good choice than a bad choice? > > I answered that already (actually, in that paragraph). But again: udev > is not trivial, and it solves a (far from) trivial problem. If some > developers think they can outsmart the kernel devs, please, lets try > it. Maybe they will. I was largely looking for an elucidation, which you provided farther up. Anyway, the discussion has been interesting and, in places, enlightening. I need to stop getting sucked back into it. :) --=20 :wq