[uml-devel] [PATCH] UBD Improvements Phase 1

[<anton.ivanov@ko...>]

From: Anton Ivanov <aivanov@...>

UBD at present is extremely slow because it handles only
one request at a time in the IO thread and IRQ handler.

The single request at a time is replaced by handling multiple
requests as well as necessary workarounds for short reads/writes.

Resulting performance improvement in disk IO - 30%

Signed-off-by: Anton Ivanov <aivanov@...>
---
 arch/um/drivers/ubd.h      |   5 ++
 arch/um/drivers/ubd_kern.c | 161 ++++++++++++++++++++++++++++++++++++++-------
 arch/um/drivers/ubd_user.c |  19 +++++-
 3 files changed, 159 insertions(+), 26 deletions(-)

diff --git a/arch/um/drivers/ubd.h b/arch/um/drivers/ubd.h
index 3b48cd2..cc1cc85 100644
--- a/arch/um/drivers/ubd.h
+++ b/arch/um/drivers/ubd.h
@@ -11,5 +11,10 @@ extern int start_io_thread(unsigned long sp, int *fds_out);
 extern int io_thread(void *arg);
 extern int kernel_fd;
 
+extern int ubd_read_poll(int timeout);
+extern int ubd_write_poll(int timeout);
+
+#define UBD_REQ_BUFFER_SIZE 64
+
 #endif
 
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index f354027..91f3354 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (C) 2015-2016 Anton Ivanov (aivanov@...)
  * Copyright (C) 2000 Jeff Dike (jdike@...)
  * Licensed under the GPL
  */
@@ -58,6 +59,17 @@ struct io_thread_req {
 	int error;
 };
 
+
+static struct io_thread_req*  (*irq_req_buffer) [];
+static struct io_thread_req * irq_remainder;
+static int irq_remainder_size;
+
+static struct io_thread_req*  (*io_req_buffer) [];
+static struct io_thread_req * io_remainder;
+static int io_remainder_size;
+
+
+
 static inline int ubd_test_bit(__u64 bit, unsigned char *data)
 {
 	__u64 n;
@@ -442,29 +454,88 @@ static void do_ubd_request(struct request_queue * q);
 static int thread_fd = -1;
 static LIST_HEAD(restart);
 
-/* XXX - move this inside ubd_intr. */
+/* Function to read several request pointers at a time
+* handling fractional reads if (and as) needed
+*/
+
+static int bulk_req_safe_read(
+	int fd,
+	struct io_thread_req*  (*request_buffer) [],
+	struct io_thread_req * remainder,
+	int * remainder_size,
+	int max_recs
+	)
+{
+	int n = 0;
+	int res = 0;
+
+	if (*remainder_size > 0) {
+		memmove(
+			(char *) request_buffer,
+			(char *) & remainder, * remainder_size
+		);
+		n = * remainder_size;
+	}
+
+	res = os_read_file(
+			fd,
+			((char *) request_buffer) + * remainder_size,
+			sizeof(struct io_thread_req *) * max_recs - *remainder_size
+		);
+	if (res > 0) {
+		n += res;
+		if ((n % sizeof(struct io_thread_req *)) > 0) {
+			/*
+			* Read somehow returned not a multiple of dword
+			* theoretically possible, but never observed in the
+			* wild, so read routine must be able to handle it
+			*/
+			*remainder_size = n % sizeof(struct io_thread_req *);
+			memmove(
+				& remainder,
+				((char *) request_buffer) + n/sizeof(struct io_thread_req *),
+				*remainder_size
+			);
+			n = n - *remainder_size;
+		}
+	} else {
+		n = res;
+	}
+	return n;
+}
+
 /* Called without dev->lock held, and only in interrupt context. */
 static void ubd_handler(void)
 {
-	struct io_thread_req *req;
 	struct ubd *ubd;
 	struct list_head *list, *next_ele;
 	unsigned long flags;
 	int n;
+	int count;
 
 	while(1){
-		n = os_read_file(thread_fd, &req,
-				 sizeof(struct io_thread_req *));
-		if(n != sizeof(req)){
+		n = bulk_req_safe_read(
+			thread_fd,
+			irq_req_buffer,
+			irq_remainder,
+			&irq_remainder_size,
+			UBD_REQ_BUFFER_SIZE
+		);
+		if(n < 0){
 			if(n == -EAGAIN)
 				break;
 			printk(KERN_ERR "spurious interrupt in ubd_handler, "
 			       "err = %d\n", -n);
 			return;
 		}
-
-		blk_end_request(req->req, 0, req->length);
-		kfree(req);
+		for (count=0;count < n /sizeof(struct io_thread_req *);count++) {
+			blk_end_request(
+				(* irq_req_buffer)[count]->req,
+				0,
+				(* irq_req_buffer)[count]->length
+			);
+			kfree((* irq_req_buffer)[count]);
+		}
 	}
 	reactivate_fd(thread_fd, UBD_IRQ);
 
@@ -1064,6 +1135,28 @@ static int __init ubd_init(void)
 		if (register_blkdev(fake_major, "ubd"))
 			return -1;
 	}
+
+	irq_req_buffer = kmalloc(
+			sizeof(struct io_thread_req *) * UBD_REQ_BUFFER_SIZE,
+			GFP_KERNEL
+		);
+	irq_remainder = 0;
+	
+	if(irq_req_buffer == NULL) {
+		printk(KERN_ERR "Failed to initialize ubd buffering\n");
+		return -1;
+	}
+	io_req_buffer = kmalloc(
+			sizeof(struct io_thread_req *) * UBD_REQ_BUFFER_SIZE,
+			GFP_KERNEL
+		);
+	
+	io_remainder = 0;
+
+	if(io_req_buffer == NULL) {
+		printk(KERN_ERR "Failed to initialize ubd buffering\n");
+		return -1;
+	}
 	platform_driver_register(&ubd_driver);
 	mutex_lock(&ubd_lock);
 	for (i = 0; i < MAX_DEV; i++){
@@ -1458,31 +1551,49 @@ static int io_count = 0;
 
 int io_thread(void *arg)
 {
-	struct io_thread_req *req;
-	int n;
+	int n, count, written, res;
 
 	os_fix_helper_signals();
 
 	while(1){
-		n = os_read_file(kernel_fd, &req,
-				 sizeof(struct io_thread_req *));
-		if(n != sizeof(struct io_thread_req *)){
-			if(n < 0)
+		n = bulk_req_safe_read(
+			kernel_fd,
+                        io_req_buffer,
+                        io_remainder,
+                        &io_remainder_size,
+                        UBD_REQ_BUFFER_SIZE
+                );
+                if(n < 0){
+                        if(n == -EAGAIN) {
+				ubd_read_poll(-1);
+				continue;
+			} else {
 				printk("io_thread - read failed, fd = %d, "
 				       "err = %d\n", kernel_fd, -n);
-			else {
-				printk("io_thread - short read, fd = %d, "
-				       "length = %d\n", kernel_fd, n);
 			}
-			continue;
+                } 
+
+                for (count=0;count < n /sizeof(struct io_thread_req *);count++) {
+			io_count++;
+			do_io((* io_req_buffer)[count]);
 		}
-		io_count++;
-		do_io(req);
-		n = os_write_file(kernel_fd, &req,
-				  sizeof(struct io_thread_req *));
-		if(n != sizeof(struct io_thread_req *))
-			printk("io_thread - write failed, fd = %d, err = %d\n",
-			       kernel_fd, -n);
+
+		written = 0;
+
+		do {
+			res = os_write_file(kernel_fd, ((char *) io_req_buffer) + written, n);
+			if (res > 0) {
+				written += res;
+			} else {
+				if (res != -EAGAIN) {
+					printk("io_thread - read failed, fd = %d, "
+					       "err = %d\n", kernel_fd, -n);
+				}
+			}
+			if (written < n) {
+				ubd_write_poll(-1);
+			}
+		} while (written < n);
 	}
 
 	return 0;
diff --git a/arch/um/drivers/ubd_user.c b/arch/um/drivers/ubd_user.c
index e376f9b..2a7d5b6 100644
--- a/arch/um/drivers/ubd_user.c
+++ b/arch/um/drivers/ubd_user.c
@@ -1,4 +1,5 @@
-/* 
+/*
+ * Copyright (C) 2016 Anton Ivanov (aivanov@...)
  * Copyright (C) 2000, 2001, 2002 Jeff Dike (jdike@...)
  * Copyright (C) 2001 Ridgerun,Inc (glonnon@...)
  * Licensed under the GPL
@@ -20,6 +21,9 @@
 
 #include "ubd.h"
 #include <os.h>
+#include <poll.h>
+
+struct pollfd kernel_pollfd;
 
 int start_io_thread(unsigned long sp, int *fd_out)
 {
@@ -32,9 +36,12 @@ int start_io_thread(unsigned long sp, int *fd_out)
 	}
 
 	kernel_fd = fds[0];
+	kernel_pollfd.fd = kernel_fd;
+	kernel_pollfd.events = POLLIN;
 	*fd_out = fds[1];
 
 	err = os_set_fd_block(*fd_out, 0);
+	err = os_set_fd_block(kernel_fd, 0);
 	if (err) {
 		printk("start_io_thread - failed to set nonblocking I/O.\n");
 		goto out_close;
@@ -57,3 +64,13 @@ int start_io_thread(unsigned long sp, int *fd_out)
  out:
 	return err;
 }
+
+int ubd_read_poll(int timeout) {
+    kernel_pollfd.events = POLLIN;
+    return poll(&kernel_pollfd, 1, timeout);
+}
+int ubd_write_poll(int timeout) {
+    kernel_pollfd.events = POLLOUT;
+    return poll(&kernel_pollfd, 1, timeout);
+}
+
-- 
2.1.4

[uml-devel] UBD Improvements (first 30%)

[<anton.ivanov@ko...>]

Hi Richard, hi list.

I had some difficulties evaluating the actual performance
difference because of the strange behaviour with the ubd speed
reduction over time (as per my earlier "There is something rotten"
email).

Overall, if I take the only the first few dd runs to read the
entire disk and compare like for like (first run without patch vs
first run with patch) I get 30% improvement on dd-ing a 16G sparse
ubd device.

The performance on find /usr -type f -exec cat {} > /dev/null \; 
increases 17%.

The patch is called "Phase 1" for a reason - by bulking the requests
we set-up the scene for a later replacement of pread/pwrite with
preadv/pwritev in next series of patches which should increase the
speed further by at least the same amount (if not more).

[uml-devel] Something is rotten in the state of Denmark

[Anton Ivanov <anton.ivanov@ko...>]

Hi Richard, hi list,

I got around to devote some time to my patchsets and while working on my
ubd block read one, I observed the following behaviour with stock 4.8.0-rc7

On a freshly booted image, stock 4.8.0-rc7, Debian jessie userspace:

root@...:~# while true; do dd if=/dev/ubda of=/dev/null bs=1M ; done
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 8.14403 s, 527 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 9.52683 s, 451 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 10.1613 s, 423 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 10.2111 s, 421 MB/s

This gets progressively worse until it reaches about 380MB/s in 5-10
more runs. The rate at which it slows down decreases overtime.

A.

Re: [uml-devel] UML build failure on 4.7

[Ritesh Raj Sarraf <rrs@re...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Disabling drivers/nvdimm (seen only on x86_64 architecture) solved the problem.

On Mon, 2016-09-05 at 18:55 +0530, Ritesh Raj Sarraf wrote:
> Hi,
> 
> I'm working on refreshing UML to version 4.7 in Debian.
> 
> The linux source tarball we use is from Debian, which is mostly the stock
> kernel.
> 
> The build failure I've run into is:
> 
>   CC [M]  lib/ts_fsm.o
>   CC [M]  lib/lru_cache.o
>   CC [M]  lib/cordic.o
>   CC [M]  lib/asn1_decoder.o
>   GEN     lib/oid_registry_data.c
>   CC [M]  lib/oid_registry.o
>   LD      virt/lib/built-in.o
>   LD      virt/built-in.o
>   LINK    vmlinux
>   LD      vmlinux.o
>   MODPOST vmlinux.o
>   GEN     .version
>   CHK     include/generated/compile.h
>   UPD     include/generated/compile.h
>   CC      init/version.o
>   LD      init/built-in.o
>   KSYM    .tmp_kallsyms1.o
>   KSYM    .tmp_kallsyms2.o
>   LD      vmlinux
>   SYSMAP  System.map
>   LINK linux
>   Building modules, stage 2.
>   MODPOST 906 modules
> ERROR: "devm_memunmap" [drivers/nvdimm/libnvdimm.ko] undefined!
> ERROR: "devm_memremap" [drivers/nvdimm/libnvdimm.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> make[2]: *** [__modpost] Error 1
> Makefile:1186: recipe for target 'modules' failed
> make[1]: *** [modules] Error 2
> make[1]: Leaving directory '/build/user-mode-linux-4.7-1um/linux-source-4.7'
> debian/rules:73: recipe for target 'build-stamp' failed
> make: *** [build-stamp] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> I: copying local configuration
> W: No local /etc/resolv.conf to copy, relying on /var/tmp/Debian-
> Build/Build//9419/etc/resolv.conf to be correct
> E: Failed autobuilding of package
> W: no hooks of type C found -- ignoring
> I: unmounting /var/tmp/lxc/ccache/ccache filesystem
> I: unmounting /var/cache/apt/archives/ filesystem
> I: unmounting dev/pts filesystem
> I: unmounting run/shm filesystem
> I: unmounting proc filesystem
> I: unmounting sys filesystem
> I: cleaning the build env 
> I: removing directory /var/tmp/Debian-Build/Build//9419 and its subdirectories
> 
> 
> The same .config builds fine for 4.6. Have others been able to build a 4.7 um
> kernel ?
> 
> 
- -- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXzYpIAAoJEKY6WKPy4XVpSQYQAKFD4ltRSAEcv8nOOqqXi8vm
W6QFp4f7QD6xehJ84yOJvOaeYG75l0/K16DaQwfDiOQT1sE4FSDVZ6SJGbvNhKKk
dmRUFzuMAli/LNJamVAfSnHsmPi33UfAPcOB28r/7cKwH1jEHBoBgP7C55VvVIrw
/r3dAJJirD447dj6fkN6qNTlBhuuNIYfq68AGBSmK33eNUMoIgOtcyoq0D2Gkvzr
VcDj2zs36jz3gbSXLdJWxctz4Li5TOsw/EW21r6+tbdogf7dZ1okvm7+dwDWQWrC
U/qb4M43ClYuL1QU4NjngyK9suPdaNBjlMTA63TnucVi0uUxrJlza9NErbRqY33+
4YDMZSEZf9WOTfNMdK3pAT2hyrEtzWP+suCg2u5IKUZu/6fea7sOK7thyCFMDBPV
gOiBFOGpKaFikDVF8b7fheQsSvesi2j38STYvBV4RBCzKuNsRdAHZBQH2sYdxi/0
PfmxSwy8jTschwaaz3NWYWgJUeH20QYSUZFgqrhNBsITud+CXKJDCpHQy8epbls3
aJAfUdZqBeQmw7tJAdUkgKmGgy/B8uF3Jo8s1Cg19QvbGVFyCbIK2SOVaD4w5VFR
rnYlfCxPFzrWqcfHriTRmvVRdFGa4x3Nfor4DocDNlrcpnO7S0j8a5dfVcflZNgc
YGwATQp2ZPTuogWJfCWO
=acar
-----END PGP SIGNATURE-----

[uml-devel] UML build failure on 4.7

[Ritesh Raj Sarraf <rrs@re...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

I'm working on refreshing UML to version 4.7 in Debian.

The linux source tarball we use is from Debian, which is mostly the stock
kernel.

The build failure I've run into is:

  CC [M]  lib/ts_fsm.o
  CC [M]  lib/lru_cache.o
  CC [M]  lib/cordic.o
  CC [M]  lib/asn1_decoder.o
  GEN     lib/oid_registry_data.c
  CC [M]  lib/oid_registry.o
  LD      virt/lib/built-in.o
  LD      virt/built-in.o
  LINK    vmlinux
  LD      vmlinux.o
  MODPOST vmlinux.o
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
  KSYM    .tmp_kallsyms1.o
  KSYM    .tmp_kallsyms2.o
  LD      vmlinux
  SYSMAP  System.map
  LINK linux
  Building modules, stage 2.
  MODPOST 906 modules
ERROR: "devm_memunmap" [drivers/nvdimm/libnvdimm.ko] undefined!
ERROR: "devm_memremap" [drivers/nvdimm/libnvdimm.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[2]: *** [__modpost] Error 1
Makefile:1186: recipe for target 'modules' failed
make[1]: *** [modules] Error 2
make[1]: Leaving directory '/build/user-mode-linux-4.7-1um/linux-source-4.7'
debian/rules:73: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
I: copying local configuration
W: No local /etc/resolv.conf to copy, relying on /var/tmp/Debian-
Build/Build//9419/etc/resolv.conf to be correct
E: Failed autobuilding of package
W: no hooks of type C found -- ignoring
I: unmounting /var/tmp/lxc/ccache/ccache filesystem
I: unmounting /var/cache/apt/archives/ filesystem
I: unmounting dev/pts filesystem
I: unmounting run/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: cleaning the build env 
I: removing directory /var/tmp/Debian-Build/Build//9419 and its subdirectories


The same .config builds fine for 4.6. Have others been able to build a 4.7 um
kernel ?


- -- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXzXJeAAoJEKY6WKPy4XVpi48P/2kATgnJeKlpU7NqbU5tn6UT
NfWnOz8JwSoAeSZZPFyfvSSSj82YNw+e/nO7T+GEzNl6o2KPmqA+g548JsKYajLN
pg43vDcz+TVUf7Yz+HHuzRpAjgKa1+iTPC6hDj98WFrkOC3NhiBZgKqUqEQ32EVE
i4ZlqM7z2G1xBOa4fIqLVxMY6ub64bUlzs98XTCjELRNmbJN0nf4zZ4IV4jOncu9
jyXacpxz/053Rx5ceZaGHiFls97uKaMPJmfUbU8/Sp5EzGmaVrXa32QUAlW8Htji
/PUzX/BU6O+PwrFalEj8Md8E4MfOtOWcXe0nctl1FAmaTfs/h17u6Zlk9Dm4kyZL
jI+OpmJsnaP9Vyyb906yZ65WNwDqoUwrSv3H0Gw4U9OAw/s2O1nY5PBMv7HRt2W4
ubkBIMv8lOhlBl9Zt2/9tgxFNIT+0UWfhKb6cFn/Lhg5W41nE954tbwSCZx858tN
rd7tZfU8URuOakaH4gP1ykYqlMdRuwf5b40D7op8qpkyGaJAazrw4KWFfIbzOQLY
WvGvrLgg9h5pQ2vOA9oQplczeyS7gxZtTvEqEesejXHMNpvigVsywUDSaRE6hnRF
JFbwNEnwszRgx2LJLS9aDvr1zWKVbWAQVbHhaVhj2v3HxR/i/JOJEymOJUSWM/ax
fVq1s9JeDQlQIHCn0PRb
=it3E
-----END PGP SIGNATURE-----

Re: [uml-devel] UML tools anywhere?

[Mattia Dongili <malattia@li...>]

On Fri, Aug 26, 2016 at 02:35:55PM -0500, Rob Landley wrote:
> On 08/17/2016 12:02 PM, Jeff Dike wrote:
> > Hi Richard,
> > 
> >> But let's ask Jeff first.
> >> Jeff, do you have a more recent SCM repo of uml-utilities?
> > 
> > No, I don't believe so.  Everything I have is out there somewhere.
> > You might check with Matt Zimmerman - he might have been doing some
> > maintenance on them.
> > 
> > 				Jeff
> 
> With this reminder, I added a quick and dirty tunctl to toybox (since I
> used it in http://landley.net/lxc/02-networking.html with kvm a while
> back). I see busybox already has one. I'm reading the kernel tuntap
> documentation file to see how to add tap support.

I think it's just a matter of a different flag (IFF_TAP instead of
IFF_TUN) to the ioctl.

-- 
mattia
:wq!

Re: [uml-devel] UML tools anywhere?

[Mattia Dongili <malattia@li...>]

On Tue, Aug 16, 2016 at 06:53:34AM -0700, Mattia Dongili wrote:
> On Mon, Aug 15, 2016 at 10:01:11PM +0200, Richard Weinberger wrote:
...
> > Mattia, do you volunteer? :-)
> 
> Sure, sounds good to me.

For the record, I'll follow-up soon. I'm waiting for approval from my
employer to make sure there is no conflict with what I'm doing.
I don't think there will be any problem, but it's a formality that I
need to get through (and it's taking a bit longer than I expected...).

-- 
mattia
:wq!

Re: [uml-devel] UML tools anywhere?

[Rob Landley <rob@la...>]

On 08/17/2016 12:02 PM, Jeff Dike wrote:
> Hi Richard,
> 
>> But let's ask Jeff first.
>> Jeff, do you have a more recent SCM repo of uml-utilities?
> 
> No, I don't believe so.  Everything I have is out there somewhere.
> You might check with Matt Zimmerman - he might have been doing some
> maintenance on them.
> 
> 				Jeff

With this reminder, I added a quick and dirty tunctl to toybox (since I
used it in http://landley.net/lxc/02-networking.html with kvm a while
back). I see busybox already has one. I'm reading the kernel tuntap
documentation file to see how to add tap support.

Is there anything else in here of general applicability to perhaps
containers? (Maybe uml_switch?)

I've wandered away from using UML because last I checked it's still
x86-only, and x86 is no longer enough of the world to justify investing
time in an architecture-specific tool. But ubuntu still says to install
this package if I want tunctl...

Rob

[uml-devel] [GIT PULL] UML fixes for 4.8-rc4

[Richard Weinberger <richard@no...>]

Linus,

The following changes since commit 7a1dcf6adaa7cc4b8cd93a3883267497a77b1051:

  Merge tag 'usercopy-v4.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2016-08-23 14:32:38 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.8-rc4

for you to fetch changes up to dad2232844073295c64e9cc2d734a0ade043e0f6:

  um: Don't discard .text.exit section (2016-08-23 23:16:16 +0200)

----------------------------------------------------------------
This pull request contains a fix for a build regression
introduced during the merge window.

----------------------------------------------------------------

Andrey Ryabinin (1):
      um: Don't discard .text.exit section

 arch/um/include/asm/common.lds.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [uml-devel] [PATCH] UML: don't discard .text.exit section

[Richard Weinberger <richard@no...>]

On 23.08.2016 11:59, Andrey Ryabinin wrote:
>> Andrey, shall I carry this patch through the UML tree or
>> do you have something else in mind?
>>
> 
> Take it in the UML tree please.

Ok! Applied to -next.

Thanks,
//richard

Re: [uml-devel] [PATCH] UML: don't discard .text.exit section

[Richard Weinberger <richard@no...>]

On 19.08.2016 17:24, Dmitry Vyukov wrote:
> If it exits then
> 
> Acked-by: Dmitry Vyukov <dvyukov@...>

Andrey, shall I carry this patch through the UML tree or
do you have something else in mind?

Thanks,
//richard

Re: [uml-devel] [PATCH] UML: don't discard .text.exit section

[Richard Weinberger <richard@no...>]

On 19.08.2016 12:48, Andrey Ryabinin wrote:
> On 08/19/2016 03:14 AM, Dmitry Vyukov wrote:
>> On Thu, Aug 18, 2016 at 3:08 AM, Andrey Ryabinin
>> <aryabinin@...> wrote:
>>>
>>>>
>>>> Sorry for delays, I am travelling.
>>>> Do we need ".fini_array" section? It's also destructors that we don't
>>>> run. Or does UML use them? Does discarding ".fini_array" help?
>>>>
>>>
>>> libc has desctructors and use them for whatever purpose it needs.
>>
>>
>> Does UML actually gracefully exit running global destructors? That
>> would also require gracefully shutting down all threads/cpus. Doesn't
>> it just _exit (or syscall(SYS_exit_group))?
>>
> 
> Sigh, I dunno, I didn't look that far. My intention was to fix build and keep old behavior unaffected.
> If you want to wipe destructors, and think that this is ok, go ahead.

UML exits like any regular C program does.
The main() function is in arch/um/os-Linux/main.c, when the kernel terminates,
hence linux_main() returns back to main() it just returns the exit code.
At this point libc's destructors will run, right?

Thanks,
//richard

Re: [uml-devel] UML tools anywhere?

[Jeff Dike <jdike@ad...>]

Hi Richard,

> But let's ask Jeff first.
> Jeff, do you have a more recent SCM repo of uml-utilities?

No, I don't believe so.  Everything I have is out there somewhere.
You might check with Matt Zimmerman - he might have been doing some
maintenance on them.

				Jeff

-- 
Jeff Dike
AddToIt
978-254-0789 (o)
978-394-8986 (c)

Re: [uml-devel] UML tools anywhere?

[Mattia Dongili <malattia@li...>]

On Mon, Aug 15, 2016 at 10:01:11PM +0200, Richard Weinberger wrote:
> On 28.07.2016 16:32, Mattia Dongili wrote:
> >> This is now:
> >> https://github.com/malattia/uml-utilities
> >>
> >>> The CVS repo on sourceforge is out of date though, it's missing a good
> >>> chunk of code. The last commit is from 2004 or so.
> >>>
> >>> If you don't have the remainder of the code history I can import a
> >>> single commit with the delta to the latest tarball.
> 
> Sorry for the late answer.
> First of all, thanks a lot for the CVS import!
> Yes, please apply the last tarball.
> 
> But let's ask Jeff first.
> Jeff, do you have a more recent SCM repo of uml-utilities?
> 
> Another question is future maintenance of the utilities.
> I'm more than busy with all my other projects and therefore
> I'd love to have somebody else to take care of uml-utilities.
> Mattia, do you volunteer? :-)

Sure, sounds good to me.
For now I'd use this mailing list for coordination, not sure a different
one makes much sense.

The code can stay on github for now, unless someone has a different
preference.

-- 
mattia
:wq!

Re: [uml-devel] UML tools anywhere?

[Richard Weinberger <richard@no...>]

On 28.07.2016 16:32, Mattia Dongili wrote:
>> This is now:
>> https://github.com/malattia/uml-utilities
>>
>>> The CVS repo on sourceforge is out of date though, it's missing a good
>>> chunk of code. The last commit is from 2004 or so.
>>>
>>> If you don't have the remainder of the code history I can import a
>>> single commit with the delta to the latest tarball.

Sorry for the late answer.
First of all, thanks a lot for the CVS import!
Yes, please apply the last tarball.

But let's ask Jeff first.
Jeff, do you have a more recent SCM repo of uml-utilities?

Another question is future maintenance of the utilities.
I'm more than busy with all my other projects and therefore
I'd love to have somebody else to take care of uml-utilities.
Mattia, do you volunteer? :-)

Thanks,
//richard

Re: [uml-devel] link error on recent kernels with CONFIG_STATIC_LINK=y

[Richard Weinberger <richard.weinberger@gm...>]

Dmitry,

We face the following issue on UML.
My ld-fu is not very strong, can you please have a look?
AFAICT it fails since UML links to libc.a and we have section clash.

On Thu, Aug 11, 2016 at 2:19 PM, Stefan Traby <stefan@...> wrote:
> hi!
>
> I get
> `.text.exit' referenced in section `.fini_array' of
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
> defined in discarded section `.text.exit' of
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)
>
> on statically linking uml (dynamic linking works).
> I use debian unstable.
>
>
> running ../bisect.sh
> Bisecting: 6495 revisions left to test after this (roughly 13 steps)
> [c3486f5376696034d0fcbef8ba70c70cfcb26f51] mm, compaction: simplify contended compaction handling
> running ../bisect.sh
> Bisecting: 3075 revisions left to test after this (roughly 12 steps)
> [9c1958fc326a0a0a533ec8e86ea6fa30977207de] Merge tag 'media/v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> running ../bisect.sh
> Bisecting: 1688 revisions left to test after this (roughly 11 steps)
> [7e4dc77b2869a683fc43c0394fca5441816390ba] Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> running ../bisect.sh
> Bisecting: 749 revisions left to test after this (roughly 10 steps)
> [25a0dc4be86fc0d8c7e81bb5f8be8427022bf15f] Merge tag 'staging-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> running ../bisect.sh
> Bisecting: 480 revisions left to test after this (roughly 9 steps)
> [b403f230448ed687edcc460cd46de652bc686b12] Merge tag 'gfs2-4.7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
> running ../bisect.sh
> Bisecting: 237 revisions left to test after this (roughly 8 steps)
> [33f4751e99601b7bfd1d66aedabd3ee9140922de] mm: thp: move pmd check inside ptl for freeze_page()
> running ../bisect.sh
> Bisecting: 118 revisions left to test after this (roughly 7 steps)
> [4c2a8499a450b6582eb5637a8f0d472168355ddd] Merge tag 'configfs-for-4.7' of git://git.infradead.org/users/hch/configfs
> running ../bisect.sh
> Bisecting: 60 revisions left to test after this (roughly 6 steps)
> [cfae7e3eb1334ff8035bb66f307f3d4010e65646] Merge tag 'for-linus-4.7b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
> running ../bisect.sh
> Bisecting: 30 revisions left to test after this (roughly 5 steps)
> [f1b5e4fac164ff43b189d996e4f05f95cc57b984] Merge tag 'acpi-urgent-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> running ../bisect.sh
> Bisecting: 15 revisions left to test after this (roughly 4 steps)
> [f97d10454e4da2aceb44dfa7c59bb43ba9f50199] Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> running ../bisect.sh
> Bisecting: 7 revisions left to test after this (roughly 3 steps)
> [ef722fd4a7592ddbfa42bcb3ad8a5caa598589b3] Revert "scripts/gdb: add documentation example for radix tree"
> running ../bisect.sh
> Bisecting: 3 revisions left to test after this (roughly 2 steps)
> [e4568d3803852d00effd41dcdd489e726b998879] mm, meminit: always return a valid node from early_pfn_to_nid
> running ../bisect.sh
> Bisecting: 1 revision left to test after this (roughly 1 step)
> [d02038f972538b93011d78c068f44514fbde0a8c] gcov: add support for gcc version >= 6
> running ../bisect.sh
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [e41f501d391265ff568f3e49d6128cc30856a36f] vmlinux.lds: account for destructor sections
> running ../bisect.sh
> e41f501d391265ff568f3e49d6128cc30856a36f is the first bad commit
> commit e41f501d391265ff568f3e49d6128cc30856a36f
> Author: Dmitry Vyukov <dvyukov@...>
> Date:   Thu Jul 14 12:07:29 2016 -0700
>
>     vmlinux.lds: account for destructor sections
>
>     If CONFIG_KASAN is enabled and gcc is configured with
>     --disable-initfini-array and/or gold linker is used, gcc emits
>     .ctors/.dtors and .text.startup/.text.exit sections instead of
>     .init_array/.fini_array.  .dtors section is not explicitly accounted in
>     the linker script and messes vvar/percpu layout.
>
>     We want:
>       ffffffff822bfd80 D _edata
>       ffffffff822c0000 D __vvar_beginning_hack
>       ffffffff822c0000 A __vvar_page
>       ffffffff822c0080 0000000000000098 D vsyscall_gtod_data
>       ffffffff822c1000 A __init_begin
>       ffffffff822c1000 D init_per_cpu__irq_stack_union
>       ffffffff822c1000 A __per_cpu_load
>       ffffffff822d3000 D init_per_cpu__gdt_page
>
>     We got:
>       ffffffff8279a600 D _edata
>       ffffffff8279b000 A __vvar_page
>       ffffffff8279c000 A __init_begin
>       ffffffff8279c000 D init_per_cpu__irq_stack_union
>       ffffffff8279c000 A __per_cpu_load
>       ffffffff8279e000 D __vvar_beginning_hack
>       ffffffff8279e080 0000000000000098 D vsyscall_gtod_data
>       ffffffff827ae000 D init_per_cpu__gdt_page
>
>     This happens because __vvar_page and .vvar get different addresses in
>     arch/x86/kernel/vmlinux.lds.S:
>
>         . = ALIGN(PAGE_SIZE);
>         __vvar_page = .;
>
>         .vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
>                 /* work around gold bug 13023 */
>                 __vvar_beginning_hack = .;
>
>     Discard .dtors/.fini_array/.text.exit, since we don't call dtors.
>     Merge .text.startup into init text.
>
>     Link: http://lkml.kernel.org/r/1467386363-120030-1-git-send-email-dvyukov@...
>     Signed-off-by: Dmitry Vyukov <dvyukov@...>
>     Reviewed-by: Andrey Ryabinin <aryabinin@...>
>     Cc: <stable@...>        [4.0+]
>     Signed-off-by: Andrew Morton <akpm@...>
>     Signed-off-by: Linus Torvalds <torvalds@...>
>
> :040000 040000 c189d7a2a48172c6adcd17cedcf55aaaef361838 4545644f4316ab845c02b31c4bb70b1399eb1a7a M      include
> bisect run success
>
> --
>
>   ciao -
>     Stefan
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel



-- 
Thanks,
//richard

[uml-devel] link error on recent kernels with CONFIG_STATIC_LINK=y

[Stefan Traby <stefan@he...>]

hi!

I get
`.text.exit' referenced in section `.fini_array' of
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o):
defined in discarded section `.text.exit' of
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o)

on statically linking uml (dynamic linking works).
I use debian unstable.


running ../bisect.sh
Bisecting: 6495 revisions left to test after this (roughly 13 steps)
[c3486f5376696034d0fcbef8ba70c70cfcb26f51] mm, compaction: simplify contended compaction handling
running ../bisect.sh
Bisecting: 3075 revisions left to test after this (roughly 12 steps)
[9c1958fc326a0a0a533ec8e86ea6fa30977207de] Merge tag 'media/v4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
running ../bisect.sh
Bisecting: 1688 revisions left to test after this (roughly 11 steps)
[7e4dc77b2869a683fc43c0394fca5441816390ba] Merge branch 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
running ../bisect.sh
Bisecting: 749 revisions left to test after this (roughly 10 steps)
[25a0dc4be86fc0d8c7e81bb5f8be8427022bf15f] Merge tag 'staging-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
running ../bisect.sh
Bisecting: 480 revisions left to test after this (roughly 9 steps)
[b403f230448ed687edcc460cd46de652bc686b12] Merge tag 'gfs2-4.7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
running ../bisect.sh
Bisecting: 237 revisions left to test after this (roughly 8 steps)
[33f4751e99601b7bfd1d66aedabd3ee9140922de] mm: thp: move pmd check inside ptl for freeze_page()
running ../bisect.sh
Bisecting: 118 revisions left to test after this (roughly 7 steps)
[4c2a8499a450b6582eb5637a8f0d472168355ddd] Merge tag 'configfs-for-4.7' of git://git.infradead.org/users/hch/configfs
running ../bisect.sh
Bisecting: 60 revisions left to test after this (roughly 6 steps)
[cfae7e3eb1334ff8035bb66f307f3d4010e65646] Merge tag 'for-linus-4.7b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
running ../bisect.sh
Bisecting: 30 revisions left to test after this (roughly 5 steps)
[f1b5e4fac164ff43b189d996e4f05f95cc57b984] Merge tag 'acpi-urgent-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
running ../bisect.sh
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[f97d10454e4da2aceb44dfa7c59bb43ba9f50199] Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
running ../bisect.sh
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[ef722fd4a7592ddbfa42bcb3ad8a5caa598589b3] Revert "scripts/gdb: add documentation example for radix tree"
running ../bisect.sh
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[e4568d3803852d00effd41dcdd489e726b998879] mm, meminit: always return a valid node from early_pfn_to_nid
running ../bisect.sh
Bisecting: 1 revision left to test after this (roughly 1 step)
[d02038f972538b93011d78c068f44514fbde0a8c] gcov: add support for gcc version >= 6
running ../bisect.sh
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[e41f501d391265ff568f3e49d6128cc30856a36f] vmlinux.lds: account for destructor sections
running ../bisect.sh
e41f501d391265ff568f3e49d6128cc30856a36f is the first bad commit
commit e41f501d391265ff568f3e49d6128cc30856a36f
Author: Dmitry Vyukov <dvyukov@...>
Date:   Thu Jul 14 12:07:29 2016 -0700

    vmlinux.lds: account for destructor sections
    
    If CONFIG_KASAN is enabled and gcc is configured with
    --disable-initfini-array and/or gold linker is used, gcc emits
    .ctors/.dtors and .text.startup/.text.exit sections instead of
    .init_array/.fini_array.  .dtors section is not explicitly accounted in
    the linker script and messes vvar/percpu layout.
    
    We want:
      ffffffff822bfd80 D _edata
      ffffffff822c0000 D __vvar_beginning_hack
      ffffffff822c0000 A __vvar_page
      ffffffff822c0080 0000000000000098 D vsyscall_gtod_data
      ffffffff822c1000 A __init_begin
      ffffffff822c1000 D init_per_cpu__irq_stack_union
      ffffffff822c1000 A __per_cpu_load
      ffffffff822d3000 D init_per_cpu__gdt_page
    
    We got:
      ffffffff8279a600 D _edata
      ffffffff8279b000 A __vvar_page
      ffffffff8279c000 A __init_begin
      ffffffff8279c000 D init_per_cpu__irq_stack_union
      ffffffff8279c000 A __per_cpu_load
      ffffffff8279e000 D __vvar_beginning_hack
      ffffffff8279e080 0000000000000098 D vsyscall_gtod_data
      ffffffff827ae000 D init_per_cpu__gdt_page
    
    This happens because __vvar_page and .vvar get different addresses in
    arch/x86/kernel/vmlinux.lds.S:
    
    	. = ALIGN(PAGE_SIZE);
    	__vvar_page = .;
    
    	.vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
    		/* work around gold bug 13023 */
    		__vvar_beginning_hack = .;
    
    Discard .dtors/.fini_array/.text.exit, since we don't call dtors.
    Merge .text.startup into init text.
    
    Link: http://lkml.kernel.org/r/1467386363-120030-1-git-send-email-dvyukov@...
    Signed-off-by: Dmitry Vyukov <dvyukov@...>
    Reviewed-by: Andrey Ryabinin <aryabinin@...>
    Cc: <stable@...>	[4.0+]
    Signed-off-by: Andrew Morton <akpm@...>
    Signed-off-by: Linus Torvalds <torvalds@...>

:040000 040000 c189d7a2a48172c6adcd17cedcf55aaaef361838 4545644f4316ab845c02b31c4bb70b1399eb1a7a M	include
bisect run success

-- 

  ciao - 
    Stefan

Re: [uml-devel] [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error: implicit declaration of function 'arch_irqs_disabled_flags'

[Richard Weinberger <richard@no...>]

Paul,

Am 15.06.2016 um 14:45 schrieb Paul E. McKenney:
> On Wed, Jun 15, 2016 at 09:05:37AM +0200, Richard Weinberger wrote:
>> Paul,
>>
>> Am 15.06.2016 um 00:54 schrieb Paul E. McKenney:
>>> On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote:
>>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>>>> head:   13ee0de9cd2444b57ce30c4f1607b49b90aa0c38
>>>> commit: f251ac814fc5787765009e60d54a2bd4277350c8 [25/36] rcu: Make call_rcu_tasks() tolerate first call with irqs disabled
>>>> config: um-allmodconfig (attached as .config)
>>>> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>>>> reproduce:
>>>>         git checkout f251ac814fc5787765009e60d54a2bd4277350c8
>>>>         # save the attached .config to linux build tree
>>>>         make ARCH=um 
>>>
>>> My kneejerk reaction would be to make CONFIG_TASKS_RCU depend on
>>> !UML or something similar.
>>>
>>> Another approach would be create a arch_irqs_disabled_flags() for UML.
>>>
>>> Any preferences?
>>
>> Patches for arch_irqs_disabled_flags() support are already on LKML:
>> https://lkml.org/lkml/2016/6/12/162
>>
>> My plan was to merge them in the v4.8 merge window.
>> So having CONFIG_TASKS_RCU depend on !UML for now should be fine.
>> We can remove the dependency in v4.8 again.
> 
> Sounds very good, thank you!

The patch is now in Linus' tree. So, you can enable CONFIG_TASKS_RCU
for UML again. :-)

Thanks,
//richard

[uml-devel] [GIT PULL] UML updates for v4.8-rc1

[Richard Weinberger <richard@no...>]

Linus,

The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:

  Linux 4.7 (2016-07-24 12:23:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.8-rc1

for you to fetch changes up to 8a545f185145e3c09348cd74326268ecfc6715a3:

  hostfs: Freeing an ERR_PTR in hostfs_fill_sb_common() (2016-08-04 00:18:10 +0200)

----------------------------------------------------------------
Beside of various fixes this pull request contains also patches
to have features such was Kcov, kmemleak and
TRACE_IRQFLAGS_SUPPORT on UML.

----------------------------------------------------------------

Amitoj Kaur Chawla (1):
      um: Eliminate null test after alloc_bootmem

Dan Carpenter (1):
      hostfs: Freeing an ERR_PTR in hostfs_fill_sb_common()

Daniel Wagner (1):
      um: Use asm-generic/irqflags.h

Richard Weinberger (4):
      um: Setup physical memory in setup_arch()
      um: Select HAVE_DEBUG_KMEMLEAK
      um: Fix possible deadlock in sig_handler_common()
      um: Enable TRACE_IRQFLAGS_SUPPORT

Vegard Nossum (1):
      um: Support kcov

 arch/um/Kconfig.common         |  5 +++--
 arch/um/include/asm/irqflags.h | 18 +++++++-----------
 arch/um/kernel/Makefile        |  5 +++++
 arch/um/kernel/initrd.c        |  2 --
 arch/um/kernel/um_arch.c       |  8 ++++----
 arch/um/os-Linux/Makefile      |  3 +++
 arch/um/os-Linux/signal.c      |  5 +++--
 arch/x86/um/vdso/Makefile      |  3 +++
 fs/hostfs/hostfs_kern.c        |  7 ++++---
 9 files changed, 32 insertions(+), 24 deletions(-)

Re: [uml-devel] [PATCH v1 0/3] Fix seccomp for UM (next)

[Kees Cook <keescook@ch...>]

On Mon, Jul 11, 2016 at 6:59 PM, Kees Cook <keescook@...> wrote:
> On Mon, Jul 11, 2016 at 5:56 PM, Mickaël Salaün <mic@...> wrote:
>> Hi,
>>
>> This series fix the recent seccomp update for the User-mode Linux architecture
>> (32-bit and 64-bit) since commit 26703c636c1f3272b39bd0f6d04d2e970984f1b6
>> (close the hole where ptrace can change a syscall out from under seccomp).
>>
>> Regards,
>>
>> Mickaël Salaün (3):
>>   um/ptrace: Fix the syscall_trace_leave call
>>   um/ptrace: Fix the syscall number update after a ptrace
>>   seccomp: Remove 2-phase API documentation
>>
>>  arch/Kconfig                  | 11 -----------
>>  arch/um/kernel/skas/syscall.c | 10 +++-------
>>  arch/x86/um/ptrace_32.c       |  3 +++
>>  arch/x86/um/ptrace_64.c       |  4 ++++
>>  4 files changed, 10 insertions(+), 18 deletions(-)
>
> Ah, perfect! Thanks for fixing this! James, can you pick this up for -next?
>
> Acked-by: Kees Cook <keescook@...>

James, can you take these fixes for v4.8? We'll need them for um to
work correctly again. (They appear to still be missing from -next.)

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [uml-devel] UML tools anywhere?

[Mattia Dongili <malattia@li...>]

On Thu, Jul 14, 2016 at 08:17:09AM -0700, Mattia Dongili wrote:
> On Thu, Jul 14, 2016 at 08:07:32AM -0700, Mattia Dongili wrote:
> > On Thu, Jul 14, 2016 at 10:33:33AM +0200, Richard Weinberger wrote:
> > > 
> > > 
> > > Am 14.07.2016 um 05:08 schrieb Mattia Dongili:
> > ...
> > > > I can certainly help with that, since I would like to do that work
> > > > anyway in order to refresh the debian package. If you want to stuff the
> > > > code in a git repository I can send patches in.
> > > 
> > > That would be great!
> > > 
> > > Step one would be converting the CVS repo to git:
> > > http://user-mode-linux.cvs.sourceforge.net/viewvc/user-mode-linux/tools/
> > > 
> > > Can you do that?
> > 
> > Here's what I got:
> > https://github.com/malattiad/uml-utilities
> 
> This is now:
> https://github.com/malattia/uml-utilities
> 
> > The CVS repo on sourceforge is out of date though, it's missing a good
> > chunk of code. The last commit is from 2004 or so.
> > 
> > If you don't have the remainder of the code history I can import a
> > single commit with the delta to the latest tarball.

Ping?

-- 
mattia
:wq!

Re: [uml-devel] User Mode Linux

[Richard Weinberger <richard@no...>]

Am 20.07.2016 um 19:47 schrieb Ritesh Raj Sarraf:
> Hello Richard,
> 
> On Wed, 2016-07-20 at 19:39 +0200, Richard Weinberger wrote:
>>> The documentation which still is active and useful[1] is marked as "old" on
>> the
>>> website.
>>> The wiki [2] on the other hand, points to a link with no content at all.
>>>  
>>> Could you please share on what the roadmap and future plans for UML are?
> 
>> Well, I maintain the UML kernel component. That meas I keep it running, fix
>> regressions
>> and try to answer questions from other developers.
>> Since I do this in my spare time there is not much time left for adding new
>> features.
> 
>> So, my roadmap is "keep it alive" :-)
> 
> 
> Okay! Thanks for the update. I had the same impression and am glad to read that
> you will continue to maintain it.
> 
>>> And for the documentation on the old site, do you have it in a Source Markup
>>> Language? What we've used now is a dump of the website from [1]
> 
>> I don't have such a dump. But I agree that we need to rework the website.
>> It is very, very old.
>> Maybe it is worth adding a UML section to http://kernelnewbies.org/?
> 
> IN my opinion, the kernel wiki may be a better option for long term maintenance.
> https://wiki.kernel.org/

Agreed.

> The main page for wiki points no login link. But once you get into one of the
> sub wikis, you can see the login link.
> Take this link for example: https://btrfs.wiki.kernel.org/index.php?title=Specia
> l:UserLogin&returnto=Main+Page
> 
> Maybe you could ask the kernel infra team to create a sub-wiki house for uml ?
> And then we can all help migrate the content ?

Just sent a request to get a wiki instance. :-)

Thanks,
//richard

Re: [uml-devel] User Mode Linux

[Ritesh Raj Sarraf <rrs@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello Richard,

On Wed, 2016-07-20 at 19:39 +0200, Richard Weinberger wrote:
> > The documentation which still is active and useful[1] is marked as "old" on
> the
> > website.
> > The wiki [2] on the other hand, points to a link with no content at all.
> > 
> > Could you please share on what the roadmap and future plans for UML are?
> 
> Well, I maintain the UML kernel component. That meas I keep it running, fix
> regressions
> and try to answer questions from other developers.
> Since I do this in my spare time there is not much time left for adding new
> features.
> 
> So, my roadmap is "keep it alive" :-)
> 

Okay! Thanks for the update. I had the same impression and am glad to read that
you will continue to maintain it.

> > And for the documentation on the old site, do you have it in a Source Markup
> > Language? What we've used now is a dump of the website from [1]
> 
> I don't have such a dump. But I agree that we need to rework the website.
> It is very, very old.
> Maybe it is worth adding a UML section to http://kernelnewbies.org/?

IN my opinion, the kernel wiki may be a better option for long term maintenance.
https://wiki.kernel.org/

The main page for wiki points no login link. But once you get into one of the
sub wikis, you can see the login link.
Take this link for example: https://btrfs.wiki.kernel.org/index.php?title=Specia
l:UserLogin&returnto=Main+Page

Maybe you could ask the kernel infra team to create a sub-wiki house for uml ?
And then we can all help migrate the content ?


For Debian, we'll keep the documentation package, and update when UML site finds
a new home.

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXj7lFAAoJEKY6WKPy4XVp8zcP/3GjLhFGfoK7TeF4YpHH9Wol
2fJQQVvSlcs2XDYoH5UKPJHDmZNQn3soOOmanrQVCfj9F5hNb5pf7DQP3YRid7sD
MMZK7V9dyCOmRwO+NxzZGH6L742vWNd1KDyJCPRi19LiVVvIRjQhO3y+MCzZve9g
LGIdSYo/3unriitm6fBOEdK1YOx70Gz/tr6IVrwzgWXvRhH76pGGWsimkibxEOw4
LSXHzZUy5NUd5Rb3JMUm+KCugIacgnJdbuqA1lCNXSMBpcjcjIOH9BBn6MNZkG6Y
B7nm+XbUjzc/whpV7iQkTOq5sMPyxjCNFqVEtVhweXlwRHAghpV9NcHVGjUVQQFz
o4kHwoYttiT/phfzYDzWOOTi8Yr0g3iBX2VkKLVYBAg3jLcITo6ySSBb2ue1LKXP
WVDZZ6ly4mHfhSgjSf730vE4hKfPmi3iYgz5ukEXwrspDy0LXjExxXhmLcgqsLaQ
dxtdr7on+N/JRMy74gQsasfCR2evTkbJsulGK4k3D7TaHhT8HimuHMcOIODO0oQx
bnOozHnT6xGWVU+B9FGV5Vw/8hVaGleVKeovLkgtY/3rZ7qVC4AgnLxLJGX22whp
RZg5+faQQaMX9IXOBT6Md+sPZj7nMGUIqO7ypzDl7FgqW7xntHriqSpIaUkD0O+c
6SiaHCKLYDAYScHYYeT+
=G/U0
-----END PGP SIGNATURE-----

Re: [uml-devel] User Mode Linux

[Richard Weinberger <richard@no...>]

Hi!

Am 20.07.2016 um 19:04 schrieb Ritesh Raj Sarraf:
> Hello Jeff, Richard and the UML Team.
> 
> Me and Mattia are maintainers for UML in the Debian Distribution.
> 
> Recently, during a refresh of the package, we realized that the User Mode Linux
> website, which hosts useful documentation, doesn't seem to have been updated in
> years.

> The documentation which still is active and useful[1] is marked as "old" on the
> website.
> The wiki [2] on the other hand, points to a link with no content at all.
> 
> Could you please share on what the roadmap and future plans for UML are?

Well, I maintain the UML kernel component. That meas I keep it running, fix regressions
and try to answer questions from other developers.
Since I do this in my spare time there is not much time left for adding new features.

So, my roadmap is "keep it alive" :-)

> And for the documentation on the old site, do you have it in a Source Markup
> Language? What we've used now is a dump of the website from [1]

I don't have such a dump. But I agree that we need to rework the website.
It is very, very old.
Maybe it is worth adding a UML section to http://kernelnewbies.org/?

Thanks,
//richard

Re: [uml-devel] User Mode Linux

[Anton Ivanov <anton.ivanov@ko...>]

I have some patches which bring network performance to > 3gbit for a single core virtual router/firewall/net device, need to find time to get them up to date and resubmit.
Some disk is improvements too.

On 20 July 2016 19:04:28 CEST, Ritesh Raj Sarraf <rrs@...> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>Hello Jeff, Richard and the UML Team.
>
>Me and Mattia are maintainers for UML in the Debian Distribution.
>
>Recently, during a refresh of the package, we realized that the User
>Mode Linux
>website, which hosts useful documentation, doesn't seem to have been
>updated in
>years.
>
>The documentation which still is active and useful[1] is marked as
>"old" on the
>website.
>The wiki [2] on the other hand, points to a link with no content at
>all.
>
>Could you please share on what the roadmap and future plans for UML
>are?
>And for the documentation on the old site, do you have it in a Source
>Markup
>Language? What we've used now is a dump of the website from [1]
>
>[1] http://user-mode-linux.sourceforge.net/old/
>[2] http://uml.harlowhill.com/
>
>- -- 
>Ritesh Raj Sarraf | http://people.debian.org/~rrs
>Debian - The Universal Operating System
>-----BEGIN PGP SIGNATURE-----
>
>iQIcBAEBCgAGBQJXj68dAAoJEKY6WKPy4XVpDEMQAJuzJVT9z2KMLYl+69RSe1wL
>VHbrT23TPVEuIBMFPxpilSbJcTGAg9XA/WJ/h+xONzAQ14rKBsoJFAvPGkZHJHsf
>aNSXNU4fI2EEPNoYCocZnQwbuReeI4up8BnIX9KxuSOmOJirbkC88YG9EfmmpjSG
>Nm8nJFZdXa8psXz7zfxH1BZyMTWDwaqfKfxvwQmrA4s0FjUY8pL/2ggEggLRsClR
>8lzxsvzs1Zt/1+wostGYCqXRfQBKfyHBUlrBBsI2GhxjEndZHQTkxR8iWCSzfAZg
>mydkz1uEDyme3Op+rSOyRgO9DTlNdnczM9/6rL6Zs4CEDyy0Xowk0BZBTV0Bd3Bw
>U5WvjgEEnyvGsmvSyY0wj7A+FdRWnlRJrCanRlPSLc1iuJAgebDDRyL7qmVIaW9Z
>JJrOgH+NLo7Yer7xpOn7esChu7Gjw1kO6IFsD9xqMVsCy5ByPMPqpDrfL5SFhMPo
>CycOalMupTjT4rRR9ocMF7XebCLIIxAT0Rvwvmyk4gbYryZZlT6pKDTe9XzmHgCN
>EMs9t8kxle0hSDT+z2FE9w5/6b6cYbAALRe305n/Xy8GmGwA1bZ/xJC761JB+TlG
>xq5jl94T9rhqQX9epquVGmgj8e9LTamm0epH1hX6yq/4j6RXK1JkOSeBqP+WtAN7
>74LAtsW3NP8g6zagx/kb
>=giYU
>-----END PGP SIGNATURE-----
>
>
>------------------------------------------------------------------------------
>What NetFlow Analyzer can do for you? Monitors network bandwidth and
>traffic
>patterns at an interface-level. Reveals which users, apps, and
>protocols are 
>consuming the most bandwidth. Provides multi-vendor support for
>NetFlow, 
>J-Flow, sFlow and other flows. Make informed decisions using capacity
>planning
>reports.http://sdm.link/zohodev2dev
>_______________________________________________
>User-mode-linux-devel mailing list
>User-mode-linux-devel@...
>https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.