Re: [uml-devel] Triage on the pending patches

Re: [uml-devel] Triage on the pending patches

[Rob Landley]

On Thursday 03 March 2005 03:22 am, Jeff Dike wrote:
> Since 2.6.11 is out, it's time to decide what patches go into mainline
> first.
>
> Here's my cut:

Well, just in case your job was too easy, here's one more.  Using the
"quiet" option shows a couple of lines being printed out by printf that
should be printed out by printk (so they'll _shut_up_ when you ask it to).

signed-off-by: Rob Landley

diff -ru linux-2.6.10/arch/um/kernel/mem_user.c linux-2.6.10-new/arch/um/kernel/mem_user.c
--- linux-2.6.10/arch/um/kernel/mem_user.c	2005-02-15 08:16:48.000000000 -0600
+++ linux-2.6.10-new/arch/um/kernel/mem_user.c	2005-02-17 05:06:25.000000000 -0600
@@ -88,8 +88,8 @@
 
 	addr = mmap(NULL, UM_KERN_PAGE_SIZE,
 		    PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE, fd, 0);
-	printf("Checking PROT_EXEC mmap in /tmp...");
-	fflush(stdout);
+	/* Honor "quiet" option */
+	printk("Checking PROT_EXEC mmap in /tmp...");
 	if(addr == MAP_FAILED){
 		err = errno;
 		perror("failed");
@@ -97,7 +97,7 @@
 			printf("/tmp must be not mounted noexec\n");
 		exit(1);
 	}
-	printf("OK\n");
+	printk("OK\n");
 	munmap(addr, UM_KERN_PAGE_SIZE);
 
 	os_close_file(fd);
diff -ru linux-2.6.10/arch/um/kernel/tt/tracer.c linux-2.6.10-new/arch/um/kernel/tt/tracer.c
--- linux-2.6.10/arch/um/kernel/tt/tracer.c	2005-02-15 08:16:49.000000000 -0600
+++ linux-2.6.10-new/arch/um/kernel/tt/tracer.c	2005-02-17 05:04:57.000000000 -0600
@@ -192,7 +192,7 @@
 	signal(SIGPIPE, SIG_IGN);
 	setup_tracer_winch();
 	tracing_pid = os_getpid();
-	printf("tracing thread pid = %d\n", tracing_pid);
+	printk("tracing thread pid = %d\n", tracing_pid);
 
 	pid = clone(signal_tramp, sp, CLONE_FILES | SIGCHLD, init_proc);
 	CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));


> The skas0 stuff needs more baking.  The os-dependent code movement I'm
> going to sit on until we have it all in hand and can clean it up.

I'm very interested in this (since I want to run UML on an unmodified host
and TT mode means a gcc compile under UML has 2/3 of the CPU usage
accounted to "system" instead of "user".  Unfortunately, I can't find out
where to go for more information.  (Every time I'm pointed at your huge
patch list I drown in x86-64 patches.  Possibly breaking out the ones that
ONLY affect a specific architecture or at least clearly marking them would
be good...)

Rob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Triage on the pending patches

[Jeff Dike]

Since 2.6.11 is out, it's time to decide what patches go into mainline first.

Here's my cut:

Plain bug-fixes -
	build
	no-kexec
	no-bb
	slirp-is-not-ethernet
	no-grep-st-ino
	fix-hostfs-gid
	usercopy-confusion
	fix-tlb-rounding
	ubd-config
	failed-net-hang
	long-command-line

Safe -
	cleanup-userspace - rearranges code
	syscall-speedup - removes code
	syscall-debug - makes some code configurable
	pread - adds a comment
	remove-useless-code - removes a no-op wrapper
	user-obj-cleanup - build cleanup
	x86_64-ldt - eliminates a reference to mm_indirect
	x86-64-warning - changes some errors from panics to printks
	error-reporting - prints out warnings where there weren't any before
	static-tty-chan - makes a bunch of things static
	stack-expansion - makes UML behave like the underlying arch
	no-mo-perl - generate config.c with sed
	

That's 23 of the 78.  We also need to resurrect the SA_NODEFER patch.

The skas0 stuff needs more baking.  The os-dependent code movement I'm going
to sit on until we have it all in hand and can clean it up.

After that, some of the cleanups like the ubd-mmap removal and tlb flush
cleaning can go.

winch-crash will be nice to get in once we have agreement that it's correct.

no-sys-ptrace seems OK, but it's large, which makes me nervous.  Maybe that's
a reason to get it in early.

fp-state is probably another good early candidate, as is no-bb.

user-constants-dep seems OK, but I just dropped in without understanding it.

random is OK, but needs a bit more work, in particular, it needs to be 
configurable.

				Jeff



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Triage on the pending patches

[Jeff Dike]

rob@landley.net said:
> Well, just in case your job was too easy, here's one more.  Using the
> "quiet" option shows a couple of lines being printed out by printf
> that should be printed out by printk (so they'll _shut_up_ when you
> ask it to). 

Those are printfs for a reason.  Early boot mesages (before the kernel is
actually running) won't be seen if they are printk-d and the thing crashes
before the console is initialized.  The messages will be stuck in the printk
buffer, and you will be none the wiser.

So, they can be made quiet if you really want, but that's not the way.

				Jeff



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Triage on the pending patches

[Rob Landley]

On Thursday 03 March 2005 01:43 pm, Jeff Dike wrote:
> rob@landley.net said:
> > Well, just in case your job was too easy, here's one more.  Using the
> > "quiet" option shows a couple of lines being printed out by printf
> > that should be printed out by printk (so they'll _shut_up_ when you
> > ask it to).
>
> Those are printfs for a reason.  Early boot mesages (before the kernel is
> actually running) won't be seen if they are printk-d and the thing crashes
> before the console is initialized.  The messages will be stuck in the
> printk buffer, and you will be none the wiser.
>
> So, they can be made quiet if you really want, but that's not the way.

I suspected there was a reason, nice to know what it is.  It would be nice if 
they could be made quiet, because I'm in the process of doing a gross hack to 
run an independent process wrapped in UML.

Basically, my nefarious scheme is to add the squashfs patch to UML, append a 
squashfs image to the end of the  UML executable, and have a cpio ramfs init 
script search through /proc/self/exe for the 32 bytes that were at the start 
of the squashfs (which includes a 4 byte magic signature thingy) to determine 
offset to pass to "losetup -o $OFFSET /dev/loop0 /proc/self/exe", and then 
mount /dev/loop0 / and run the executable I want out of that filesystem.

And there's a cheap and dirty way to get a self contained program running 
under UML.  (I hope to actually have an example working this evening using 
2.6.11.)

The down side is that UML (even with the quiet option) just won't shut up 
about its init stuff.  Hence me looking into cleaning that up...

> 				Jeff

Rob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Triage on the pending patches

[Blaisorblade]

On Friday 04 March 2005 03:11, Rob Landley wrote:
> On Thursday 03 March 2005 01:43 pm, Jeff Dike wrote:
> > rob@landley.net said:
> > > Well, just in case your job was too easy, here's one more.  Using the
> > > "quiet" option shows a couple of lines being printed out by printf
> > > that should be printed out by printk (so they'll _shut_up_ when you
> > > ask it to).
> >
> > Those are printfs for a reason.  Early boot mesages (before the kernel is
> > actually running) won't be seen if they are printk-d and the thing
> > crashes before the console is initialized.  The messages will be stuck in
> > the printk buffer, and you will be none the wiser.
>
> I suspected there was a reason, nice to know what it is.  It would be nice
> if they could be made quiet, because I'm in the process of doing a gross
> hack to run an independent process wrapped in UML.

> Basically, my nefarious scheme is to add the squashfs patch to UML, append
> a squashfs image to the end of the  UML executable, and have a cpio ramfs
> init script search through /proc/self/exe for the 32 bytes that were at the
> start of the squashfs (which includes a 4 byte magic signature thingy) to
> determine offset to pass to "losetup -o $OFFSET /dev/loop0 /proc/self/exe",
> and then mount /dev/loop0 / and run the executable I want out of that
> filesystem.
First, compliments.... we need such stuff going.

Please note that unless I'm mistaken the above scheme does not work 
since /proc/self/exe contains what you want on the host, not on the guest. If 
you use hostfs then it's ok, otherwise you'll have to pack the squashfs 
within the cpio image (if it's possible, the cpio image could not be ready to 
cope with so much data). Also, made sure adding stuff at the end of an exec. 
file is accepted without problems? Seems reasonable but not obvious.

No experience with such stuff, but isn't it a bit risky this way (a signature 
being there by mistake)? If you still go for grepping the exec. image, I 
would add a header in the end giving the size of the squashfs image, and 
parse it. With the -s option to losetup you can cut at the end the area 
seeing by the loop device.
> And there's a cheap and dirty way to get a self contained program running
> under UML.  (I hope to actually have an example working this evening using
> 2.6.11.)

> >
> > So, they can be made quiet if you really want, but that's not the way.
> The down side is that UML (even with the quiet option) just won't shut up
> about its init stuff.  Hence me looking into cleaning that up...
Add early_printk which is a printf but shuts down when the quiet option is 
used.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Triage on the pending patches

[Rob Landley]

On Saturday 05 March 2005 10:57 am, Blaisorblade wrote:
> > Basically, my nefarious scheme is to add the squashfs patch to UML,
> > append a squashfs image to the end of the  UML executable, and have a
> > cpio ramfs init script search through /proc/self/exe for the 32 bytes
> > that were at the start of the squashfs (which includes a 4 byte magic
> > signature thingy) to determine offset to pass to "losetup -o $OFFSET
> > /dev/loop0 /proc/self/exe", and then mount /dev/loop0 / and run the
> > executable I want out of that filesystem.
>
> First, compliments.... we need such stuff going.
>
> Please note that unless I'm mistaken the above scheme does not work
> since /proc/self/exe contains what you want on the host, not on the guest.
> If you use hostfs then it's ok, otherwise you'll have to pack the squashfs
> within the cpio image (if it's possible, the cpio image could not be ready
> to cope with so much data).

That would suck mightily, since it would decompress it into ram and then eat 
swap space instead of using the file as backing store.

No, I'm a big fan of hostfs.  Part of this will probably involve changing the 
default command line of UML to something like:

rootfstype=hostfs rootflags=/ rw quiet mem=48M

Or some such.  Then /proc/self/exe is quite happy, and I can find my file to 
loopback mount it.  I can also chdir to (a readlink of) /proc/self/cwd, so 
that whatever application I'm running is working in the right current 
directory.

I think I can make it relatively transparent to the hosted application, even.  
If I want to get silly I can su away from root so things like tar aren't 
confused that they can't do mknod and chown and such, or else I can mount a 
loopback ext2 filesystem on /tmp or some such hack to give it space it can 
play permission games with...

> Also, made sure adding stuff at the end of an 
> exec. file is accepted without problems? Seems reasonable but not obvious.

If it's ELF, life should be good because the elf sections say where everything 
is and how long it is.  (Non-elf, you're on your own.)

I pondered making all this an elf section, but don't know how off the top of 
my head...

> No experience with such stuff, but isn't it a bit risky this way (a
> signature being there by mistake)? If you still go for grepping the exec.
> image, I would add a header in the end giving the size of the squashfs
> image, and parse it. With the -s option to losetup you can cut at the end
> the area seeing by the loop device.

I could do that.  Squashfs starts with a (4 byte) magic number, and I was 
worried that was insufficient so I'm grabbing the first 32 bytes to reduce 
the possibility of collisions.  (The random occurrence of 32 identical bytes 
is really really unlikely if those bytes are at all well distributed.  Not 
quite 1 in 2^256 unlikely, but pretty darn up there.  I'm basically waiting 
for the easy way to break, and implementing something else if it does.)

Sticking the length on the end is another quite valid option.  I don't even 
have to tell losetup to truncate the loop device because none of the 
filesystems I care about are put off by trailing garbage...

> Add early_printk which is a printf but shuts down when the quiet option is
> used.

Cool.  Will do.

Thanks,

Rob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel