[lxc-devel] [PATCH] Support MS_SHARED / - issues calling MAKEDEV

[Michael H. Warfield]

More on the MAKEDEV debacle...

On Mon, 2013-01-07 at 09:48 -0600, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > On Sun, 2013-01-06 at 06:39 +0800, Alexander Vladimirov wrote:
> > > It is a separate package in Arch Linux and I dont have it installed on
> > > the host, as well as in container since everything works well without
> > > it
> > 
> > Well, that would explain it.  What isn't explained is why we need it.
> 
> (see my previous response)
> 
> > This is the run_makedev() function which is called from setup_autodev()
> > in src/lxc/setup.c just before it tries to populate the .../dev
> > directory in the container.  There's some comments in there about making
> > sure the /dev/vcs* entries are created.

> Right.

> > It's also not clear to me if it's even doing what it perports to do.  It
> > changes to the dev directory and then runs /sbin/MAKEDEV (without
> > checking if it even exists)

> Right, that should be fixed,

> > without a parameter (-d) for the target
> > directory which would seem to me to cause MAKEDEV to attempt to create

> At least my copy of makedev creates the devices in $cwd.

> If adding -d is needed for other distros, of course I have 0 objections.

This whole thing with MAKEDEV is looking more and more like a morass
with no way to cleanly resolve it.

> > the devices in the host /dev and not the container .../dev directory at
> > all.  That actually appears consistent with the behavior I'm seeing.  If
> > I reboot the host system, all those tty devices do not exist in the host

> ?  In the host /dev, or in the /var/lib/lxc/$container/rootfs/dev?

If I reboot the (F17 / F18beta host) without starting any containers, I
have a number of tty devices [0-63] and vcs/vsca devices for [1-6] in
the host /dev.

If I create my own little private ~/dev and cd into it and type "MAKEDEV
-d ${PWD} console" I get something like almost 3800 devices (most of
them tty devices) and no vcs or vcsa devices (so it's not even doing
what it is we're wanting it to do).

Now...  If I start up a container with audodev=1, now I get the 3700+
tty devices created in the host /dev while the container /dev has
tty[1-6] created by lxc-start itself (I specified 6 virtual consoles)
but no vcs / vcsa devices.

Now...  In the MAKEDEV man pages I see this:

== 
MAKEDEV  doesn't actually know anything about devices.  It reads all of
the information from files stored in /etc/makedev.d.
== 

Ok...  So it's off to /etc/makedev.d we go.  The vcs/vcsa devices are
defined in the file 01linux-2.6.x on "$VCSA" lines while console is on a
"$CONSOLE" line.  There's a whole RAFT of various
tty{S,U,E,MX,SR,T,t,USB}{n} devices defined in that file on "$SERIAL"
lines.

The man page documentation on MAKEDEV indicates that "makedev console"
should create the vcs and vcsa devices, but it does not seem to.  But it
does seem to be creating all these devices defined on the $SERIAL lines
whether they exist or not (I suspect that even my Computone Intelliport
Serial board devices are listed in there even though the driver module
is no longer compiled in these kernels at all).

Running "MAKEDEV -d ${PWD} vcsa" created the vcs/vcsa devices under my
private ~/dev but it created a whole pile of them too, not just what's
needed.

If we were to call MAKEDEV at all, shouldn't we use the configuration
directory in the container ( i.e. MAKEDEV -s ${container
rootfs}/etc/makedev.d )?  But, then there's the differences between
MAKEDEV between distros, even if MAKEDEV exists.  Since MAKEDEV is all
configuration driven and varies from distro to distro, I'm not sure
there's a way out of this swamp calling MAKEDEV.

If all we need it for is the vcs / vcsa virtual console snapshot devices
and there's a 1:1 correlation between those and the tty devices,
wouldn't it be better to just create them along side the corresponding
tty devices?

Are we sure we need them?  The tty{n} devices are bind mounts from ptys,
correct?  If so, what is the correct action for the vcs (virtual console
snapshot) and vcsa (virtual console snapshot w/ attributes) devices?
Are snapshots even possible using the ptys that are bound?  Seems to me
that we risk running into problems creating them as devices that could
conflict with the host virtual consoles.

What other devices do we need?  I don't see "MAKEDEV console" on Fedora
creating anything other than this set:

console
tty{n}
tty{A}{n}

We're already creating console and tty{n} and we probably don't need
tty{a}{n} (serial devices are ttyS{n} and USB serial ports would be
ttyUSB{n}).  Maybe it's buying us something more under an Ubuntu host.
I have MAKEDEV version 3.24 from Fedora.

> If the former, I don't see what the container to do to affect the host's
> boot sequence.

It's the former when you call MAKEDEV from within the run_makedev()
function.  The MAKEDEV command defaults to /dev on Fedora unless you
specify the -d option.  Maybe it defaults to ${CWD} on Ubuntu but not in
Fedora or RHEL derivatives.

> > until after I fire up a container with autodev enabled.  Then they
> > appear in the host /dev which is not the correct behavior.

> No it's not.

> > I don't think we should be doing this but this is part of the earlier
> > autodev patches Serge did for systemd that went into 9.0.0.a1.  Maybe
> > it's a difference in behavior between MAKEDEV on Ubuntu vs MAKEDEV on
> > Fedora (et al) and not even guaranteed to exist.

> Sounds like it.

> > Serge?

> -serge

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130108/7c1902ed/attachment.pgp>