Re: [mer-general] Mer Platform SDK: a new approach to mounting.

2013-01-18 Thread David Greaves
Thanks - this looks really promising.

I'd never heard of unshare before.

I'll put together a package so people can try it.

David

On 18/01/13 01:08, Oleg Girko wrote:
 Hi!
 
 After being hit by Mer SDK unmounting issue caused by system mounts shared by 
 default, I've spent several hours to find a better way to mount directories 
 to 
 Mer SDK chroot.
 
 The resulting patch to mer-sdk-chroot script is attached to this email.
 It can be applied directly to https://github.com/mer-tools/sdk-setup/
 
 The new approach eliminates the need for explicit mount and umount steps.
 All necessary mounts are preformed in private namespace when entering chroot.
 When chrooted process ends, its namespace is discarded by the kernel.
 
 As a result, the remaining enter and exec commands are not needed as well,
 because they do essentially the same: running a process with private 
 namespace 
 in chroot.
 
 Therefore, the new command line syntax has no action argument and looks like:
   mer-sdk-chroot [options] [command args...]
 
 Best regards,
 -- Oleg Girko, http://www.infoserver.ru/~ol/


-- 
Don't worry, you'll be fine; I saw it work in a cartoon once...




[mer-general] Mer Platform SDK: a new approach to mounting.

2013-01-17 Thread Oleg Girko
Hi!

After being hit by Mer SDK unmounting issue caused by system mounts shared by 
default, I've spent several hours to find a better way to mount directories to 
Mer SDK chroot.

The resulting patch to mer-sdk-chroot script is attached to this email.
It can be applied directly to https://github.com/mer-tools/sdk-setup/

The new approach eliminates the need for explicit mount and umount steps.
All necessary mounts are preformed in private namespace when entering chroot.
When chrooted process ends, its namespace is discarded by the kernel.

As a result, the remaining enter and exec commands are not needed as well,
because they do essentially the same: running a process with private namespace 
in chroot.

Therefore, the new command line syntax has no action argument and looks like:
  mer-sdk-chroot [options] [command args...]

Best regards,
-- Oleg Girko, http://www.infoserver.ru/~ol/From ea8b1d268277da758798382bf392ffb029d02e1d Mon Sep 17 00:00:00 2001
From: Oleg Girko ol+...@infoserver.ru
Date: Thu, 17 Jan 2013 22:45:43 +
Subject: [PATCH] Make all mounts to be performed in a private namespace.

This makes mount and umount commands unnecessary because all mounts
are done in a private namespace during enter or exec phases.
Also, enter and exec commands are unnecessary as well because
action to be performed can be determined by presence of command name and args.
Hence, no action is needed to be specified;
the new command line syntax looks like this:
mer-sdk-chroot [command args...]

Signed-off-by: Oleg Girko ol+...@infoserver.ru
---
 src/mer-sdk-chroot | 250 +
 1 file changed, 40 insertions(+), 210 deletions(-)

diff --git a/src/mer-sdk-chroot b/src/mer-sdk-chroot
index 0702f2a..bdc4188 100755
--- a/src/mer-sdk-chroot
+++ b/src/mer-sdk-chroot
@@ -9,39 +9,24 @@
 usage()
 {
 cat EOF
-usage: $0 [-u user] [-r SDK root path] [enter]
-   $0 [-u user] [-r SDK root path] exec command args ..
-   $0 [-u user] [-m all|none|root|home] [-r SDK root path]  mount 
-   $0 [-r SDK root path] umount
+usage: $0 [-u user] [-m all|none|root|home] [-r SDK root path] [command args ..]
+   $0 -h
 
This is the Mer chroot SDK.
For information see http://wiki.merproject.org/wiki/Platform_SDK
 
-   The SDK has 4 commands:
-  enter (default)
-  exec
-  mount
-  umount
-
-  enter
- Used to enter the SDK and begin working. The SDK bash shell is a
+  If command is not present,
+ used to enter the SDK and begin working. The SDK bash shell is a
  login shell. See below for .profile handling
  Must be preceded by a 'mount' to setup the SDK.
  May be used in multiple terminals and simply enters the
  chroot
 
-  exec
- Used to execute an arbitrary command from within the SDK chroot
+  If command is present,
+ used to execute an arbitrary command from within the SDK chroot
  environment. The environment variable MERSDK is set to 1 to allow
  SDK detection.
 
-  mount
- Used to setup the SDK mountpoints. Only needed once per login
- session
-
-  umount
- Used to clean up the SDK mountpoints before removing the SDK.
-
   Options:
 
-u  System user to link into SDK (not needed if using sudo)
@@ -49,6 +34,7 @@ usage()
root, home
-r The root of the SDK to use - normally derived from the
   pathname of $0
+   -h  Show this help
 
   Profile
 
@@ -83,18 +69,18 @@ if [[ $EUID -ne 0 ]]; then
 exit 1
 fi
 
+if cmp -s /proc/$PPID/mountinfo /proc/self/mountinfo; then
+exec unshare -m -- $0 $@
+echo $0 must be run in private namespace and unshare failed; exiting
+exit 1
+fi
+
 # Use the SUDO value if present
 user=$SUDO_USER || true;
 
 bind_mount_root=yes;
 bind_mount_home=yes;
 
-# Support the action being given as the first non-option arg
-if [ ${1:0:1} != - ]; then
-action=$1
-shift
-fi
-
 while getopts u:m:r: opt; do
 case $opt in
 	u ) user=$OPTARG;;
@@ -113,7 +99,7 @@ while getopts u:m:r: opt; do
 		exit 1;;
 	esac ;;
 	r ) sdkroot=$OPTARG;;
-	\? ) usage
+	h|\? ) usage
 exit 1;;
 	: ) echo Option -$OPTARG requires an argument. 2
 	usage
@@ -137,21 +123,9 @@ if [[ ! -f ${sdkroot}/etc/MerSDK ]] ; then
 exit 1
 fi
 
-# We need the SDK to be under a --make-unbindable mount otherwise it
-# appears in other SDKs. We also need $sdkroot *not* to be
-# --make-unbindable since things like mic want to make bind mounts in
-# there.
-# We can't just make .. --make-unbindable since it may be something
-# special (eg if the SDK is installed straight into $HOME or / that
-# would break stuff)
-# Solution - force an intermediate 'sdks' directory for now. We could
-# do this in the .ks for chroot SDKs but that gets messy too.
-sdkparent=$(dirname $sdkroot)
-if [[ $(basename $sdkparent) !=