public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: William Hubbs <williamh@gentoo.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, mpagano@gentoo.org,
	ryao@gentoo.org, gregkh@gentoo.org,
	torvalds@linux-foundation.org, w.d.hubbs@gmail.com
Subject: Re: [PATCH] init: fix name of root device in /proc/mounts
Date: Thu, 21 Mar 2013 22:00:46 -0500	[thread overview]
Message-ID: <1363921246.15703.54@driftwood> (raw)
In-Reply-To: <20130320211125.GA26595@linux1> (from williamh@gentoo.org on Wed Mar 20 16:11:25 2013)

On 03/20/2013 04:11:25 PM, William Hubbs wrote:
> On Wed, Mar 20, 2013 at 02:03:20AM -0500, Rob Landley wrote:
> > On 03/19/2013 07:20:17 PM, William Hubbs wrote:
> > > On Tue, Mar 19, 2013 at 04:17:11PM -0700, H. Peter Anvin wrote:
> > > > On 03/19/2013 03:28 PM, William Hubbs wrote:
> > > > > The issue is that /dev/root appears in /proc/mounts if you do  
> not
> > > > > boot with an initramfs, but /dev/root is not a device node.  
> In the
> > > > > past, udev created a symbolic link from /dev/root to the
> > > > > appropriate block device, but it does not do this any longer.
> > > Also,
> > > > > devtmpfs does not create this symbolic link.
> > > > >
> > > > > This is causing bugs with software that depends on the  
> existence
> > > > > of /dev/root [2] for example.
> > > >
> > > > Seems okay to me, although even better would be to use the udev  
> name
> > > > of the device in question.
> > >
> > > I'm not following what you mean.
> > >
> > > The problem is that "/dev/root" should not be in /proc/mounts,
> > > since there is always another entry that points to the root
> > > file system.
> >
> > What gave you that idea?
> >
> > wget http://landley.net/aboriginal/bin/system-image-i686.tar.bz2
> > extract it and ./run-emulator.sh and in there:
> >
> > (i686:1) /home # cat /proc/mounts
> > rootfs / rootfs rw 0 0
> > /dev/root / squashfs ro,relatime 0 0
> > proc /proc proc rw,relatime 0 0
> > sys /sys sysfs rw,relatime 0 0
> > dev /dev devtmpfs rw,relatime,size=63072k,nr_inodes=15768,mode=755  
> 0 0
> > dev/pts /dev/pts devpts rw,relatime,mode=600 0 0
> > /tmp /tmp tmpfs rw,relatime 0 0
> > /home /home tmpfs rw,relatime 0 0
> >
> > Userspace can totally determine what /dev/root points to, I made  
> mdev
> > do it in 2006 (udev started doing so shortly thereafter). Busybox  
> git
> > commit a7e3d052.:4
> 
> There are situations where it doesn't work though -- suppose that root
> is btrfs for example.

So you're saying there's a bug in btrfs?

> Also, the other message that answered you is correct, the udev
> maintainers say we should not be relying on /dev/root at all so to  
> make
> it work distro packagers have to add a rule themselves.

These udev maintainers?

   http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01889.html

This is the udev that got Katamari'd into systemd, not one of the forks  
that ran screaming trying not to get sucked into the latest escapade of  
King of All Cosmos?

Look, if you want to add /dev/root to devtmpfs, that makes a certain  
amount of sense. But your patch seems to have missed do_mounts.c doing:

   if (strncmp(root_device_name, "/dev/", 5) == 0)
     root_device_name += 5;

Which means that if the user does "root=sda1" on the kernel command  
line you're not passing an absolute path to create_dev():

-	create_dev("/dev/root", ROOT_DEV);
-	mount_block_root("/dev/root", root_mountflags);
+	if (saved_root_name[0]) {
+		create_dev(saved_root_name, ROOT_DEV);

And last I checked that means /proc/mounts will have a relative path in  
it...

I.E. you're modifying kernel code you're not familiar with to fix a  
non-problem caused by your unfamiliarity with the corresponding  
userspace code. I'm really not seeing the upside here.

Rob

  parent reply	other threads:[~2013-03-22  3:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31 22:51 [PATCH] init: fix name of root device in /proc/mounts William Hubbs
2013-01-31 23:22 ` H. Peter Anvin
2013-02-01 17:14   ` William Hubbs
2013-02-01 19:03     ` H. Peter Anvin
2013-02-05  2:42   ` Rob Landley
2013-02-05  2:54     ` H. Peter Anvin
2013-02-05  4:19       ` William Hubbs
2013-03-17 22:23       ` William Hubbs
2013-03-19 22:28       ` William Hubbs
2013-03-19 23:17         ` H. Peter Anvin
2013-03-20  0:20           ` William Hubbs
2013-03-20  0:24             ` H. Peter Anvin
2013-03-20  7:03             ` Rob Landley
2013-03-20 15:02               ` H. Peter Anvin
2013-03-20 21:11               ` William Hubbs
2013-03-20 21:46                 ` Kay Sievers
2013-03-22  3:00                 ` Rob Landley [this message]
2013-02-09 21:32 ` William Hubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1363921246.15703.54@driftwood \
    --to=rob@landley.net \
    --cc=gregkh@gentoo.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpagano@gentoo.org \
    --cc=ryao@gentoo.org \
    --cc=torvalds@linux-foundation.org \
    --cc=w.d.hubbs@gmail.com \
    --cc=williamh@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox