Re: [uml-devel] os_lock_file removal

2005-06-24 Thread Jeff Dike
On Fri, Jun 24, 2005 at 03:19:53PM -0400, Allan Graves wrote: > Hi guys. I'm working on developing a cluster file system and I'd like > to simulate concurrent shared storage access using uml and disk files. > I traced down the file locking, and it seems that (assuming I have a > cluster file s

[uml-devel] os_lock_file removal

2005-06-24 Thread Allan Graves
Hi guys. I'm working on developing a cluster file system and I'd like to simulate concurrent shared storage access using uml and disk files. I traced down the file locking, and it seems that (assuming I have a cluster file system that keeps things up to date in the metadata of the filesystem)

Re: [uml-devel] [PATCH] UML - TT_MODE build fix

2005-06-24 Thread Blaisorblade
On Friday 24 June 2005 08:11, Raphael Bossek wrote: > Using of the preprocessor define SUBARCH as part of an directory > name does not work in linux-2.6.12/arch/um/kernel/uml.lds.S: > > arch/um/sys-SUBARCH/unmap_fin.o => arch/um/sys- i386 /unmap_fin.o > > This patch works with linux 2.6.12-mm1 and

Re: [uml-devel] Linking .tmp_vmlinuux1 fails with 2.6.12-mm1

2005-06-24 Thread Jeff Dike
On Fri, Jun 24, 2005 at 08:23:45AM +0200, Raphael Bossek wrote: > after applying the TT_MODE build patch I run into the following problem > with linux 2.6.12-mm1: > arch/um/sys-i386/built-in.o(*ABS*+0x73c706fe): In function `__crc_kunmap': > module.c: multiple definition of `__crc_kunmap' > arch/u

Re: [uml-devel] Linking .tmp_vmlinuux1 fails with 2.6.12-mm1

2005-06-24 Thread Blaisorblade
On Friday 24 June 2005 08:23, Raphael Bossek wrote: > Hi, > > after applying the TT_MODE build patch I run into the following problem > with linux 2.6.12-mm1: Does that happen with 2.6.12-current? Here it seems it doesn't; so I'll have to look into -mm only; otherwise I'll look at gcc-2.95 differe

Re: [uml-devel] Question about the unexpected signal 11 when fork in UML-2.6.7 TT mode

2005-06-24 Thread Blaisorblade
On Friday 24 June 2005 11:57, Alex LIU wrote: > I just let the SIGSEVG go and return from the sleeping_process_signal > function instead of tracer_panic and hanging the UML. It seems ok. Is it > dangerous? Thanks a lot! The sleeping process will get the SIGSEGV, with whatever content it has; hopef

RE: [uml-devel] Question about the unexpected signal 11 when fork in UML-2.6.7 TT mode

2005-06-24 Thread Alex LIU
I just let the SIGSEVG go and return from the sleeping_process_signal function instead of tracer_panic and hanging the UML. It seems ok. Is it dangerous? Thanks a lot! Alex -Original Message- From: Blaisorblade [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 11:42 PM To: user-mod