Re: What would it take....

Samuel Thibault wrote: > Good morning :) Good afternoon:-) > > Da Zheng, le Thu 24 Dec 2009 08:50:14 +0800, a écrit : >> So has network-transparent IPC been removed from microkernel or not? > > See DEVELOPMENT: > > Support for NORMA was removed on 2006-03-20. >

Re: What would it take....

Good morning :) Da Zheng, le Thu 24 Dec 2009 08:50:14 +0800, a écrit : > So has network-transparent IPC been removed from microkernel or not? See DEVELOPMENT: Support for NORMA was removed on 2006-03-20. . Samuel

Re: What would it take....

olafbuddenha...@gmx.net wrote: > Hi, > > On Tue, Dec 22, 2009 at 02:31:46PM +0100, Tim Kack wrote: > >> 3. What would it take to enable SMP and/or NORMA-RPC? > > I think we actually nuked NORMA support from GNU Mach... Or at least we > discussed that. > > Doi

Re: What would it take....

olafbuddenha...@gmx.net, le Wed 23 Dec 2009 16:28:58 +0100, a écrit : > > > > 3. What would it take to enable SMP and/or NORMA-RPC? > > > > > > No real development as GNU Mach is already supposed to be SMP-safe. > > > Problem is that the drivers are old and

Re: What would it take....

Hi, On Tue, Dec 22, 2009 at 02:31:46PM +0100, Tim Kack wrote: > 3. What would it take to enable SMP and/or NORMA-RPC? I think we actually nuked NORMA support from GNU Mach... Or at least we discussed that. Doing network-transparent IPC at the microkernel level is probably not a good idea.

Re: What would it take....

Hi, On Tue, Dec 22, 2009 at 03:19:26PM +0100, Tim Kack wrote: > On Tue, 2009-12-22 at 14:51 +0100, Samuel Thibault wrote: > > Tim Kack, le Tue 22 Dec 2009 14:31:46 +0100, a écrit : > > > 1. What would it take to bring the device driver layer (which is > > > from Linu

Re: What would it take....

Samuel Thibault wrote: >> Is there anything else we should worry about? > > Ordering. See /usr/src/linux/Documentation/memory-barriers.txt It's a long file. There are a lot to study:) > >> Then the use of volatile is very limited and the only case I can think of is >> something like signal handl

Re: What would it take....

Da Zheng, le Wed 23 Dec 2009 19:17:43 +0800, a écrit : > If we declare all shared variables are volatile, it certainly work but there > is serious performance penalty here. I think that's why people prefer to use > spin_lock or mutex to protect other variables. Yes. > I think the difference in

Re: What would it take....

Samuel Thibault wrote: > Samuel Thibault, le Wed 23 Dec 2009 10:26:09 +0100, a écrit : >> Da Zheng, le Wed 23 Dec 2009 16:46:34 +0800, a écrit : If you use volatile, the compiler won't optimise instructions so it would "work" too ; note however that it's not SMP safe (it may even not

Re: What would it take....

Hi, Samuel Thibault wrote: > Da Zheng, le Wed 23 Dec 2009 16:46:34 +0800, a écrit : >>> If you use volatile, the compiler won't >>> optimise instructions so it would "work" too ; note however that it's >>> not SMP safe (it may even not be premption-safe, depending on which >>> instruction the comp

Re: What would it take....

Samuel Thibault, le Wed 23 Dec 2009 10:26:09 +0100, a écrit : > Da Zheng, le Wed 23 Dec 2009 16:46:34 +0800, a écrit : > > > If you use volatile, the compiler won't > > > optimise instructions so it would "work" too ; note however that it's > > > not SMP safe (it may even not be premption-safe, dep

Re: What would it take....

Da Zheng, le Wed 23 Dec 2009 16:46:34 +0800, a écrit : > > If you use volatile, the compiler won't > > optimise instructions so it would "work" too ; note however that it's > > not SMP safe (it may even not be premption-safe, depending on which > > instruction the compiler eventually uses). > We do

Re: What would it take....

Hi, Samuel Thibault wrote: >> (or volatile variable + memory barrier) > > You do not need both. If you use a memory barrier, you don't need to > tell the compiler "volatile", since the memory barrier already tells it > that things may have changed. If you use volatile, the compiler won't > optimi

Re: What would it take....

Da Zheng, le Wed 23 Dec 2009 15:49:01 +0800, a écrit : > One more thing: is it enough to only use something like spin_lock to protect > a variable in shared memory between two processes? Yes. > (or volatile variable + memory barrier) You do not need both. If you use a memory barrier, you don't

Re: What would it take....

Samuel Thibault wrote: > Da Zheng, le Wed 23 Dec 2009 10:21:50 +0800, a écrit : >>> Anyway, deciding between shared memory or pure IPC is not really an >>> issue. I believe the more difficult part is how to make process >>> actually perform IPCs securely. It can probably be useful to check how >>

Re: What would it take....

Da Zheng, le Wed 23 Dec 2009 10:21:50 +0800, a écrit : > > Anyway, deciding between shared memory or pure IPC is not really an > > issue. I believe the more difficult part is how to make process > > actually perform IPCs securely. It can probably be useful to check how > > shm was implemented. >

Re: What would it take....

Hi, Samuel Thibault wrote: >> Then must process-shared semaphores and mutexes be implemented in >> shared memory? or it's completely through IPCs? > > Note that posix mutexes are always shared between processus through > shared memory anyway (the application is responsible for sharing the > memor

Re: What would it take....

Da Zheng, le Wed 23 Dec 2009 09:35:03 +0800, a écrit : > Samuel Thibault wrote: > >> When process-shared semaphores and mutexes themselves are in the shared > >> memory, can we not use the similar implementation as the ones in the same > >> process? > > > > The implementation uses Mach messages,

Re: What would it take....

Hi, Samuel Thibault wrote: >> When process-shared semaphores and mutexes themselves are in the shared >> memory, can we not use the similar implementation as the ones in the same >> process? > > The implementation uses Mach messages, so it's basically the same thing. > With different tasks, you

Re: What would it take....

Samuel Thibault wrote: > Da Zheng, le Tue 22 Dec 2009 23:04:55 +0800, a écrit : >> I think we need to use process-shared mutexes, > > Or better, process-shared condition variables. I'm not talking about sleep/wakeup signaling:-) why do we need to condition variables to protect shared variables?

Re: What would it take....

Da Zheng, le Tue 22 Dec 2009 23:04:55 +0800, a écrit : > I think we need to use process-shared mutexes, Or better, process-shared condition variables. > which is what I meant in the beginning. Ok. > When we protect the shared variable with a mutex, I don't think we > need to use RPCs to synchr

Re: What would it take....

Samuel Thibault wrote: >> If Hurd's RPCs have to be used when we synchronize relevant operations, we >> might not get any benefit by using shared memory. > > You do not need RPCs all the time, just when starting/finishing > processing items. While processing others can arrive and will get > proce

Re: What would it take....

Da Zheng, le Tue 22 Dec 2009 22:29:08 +0800, a écrit : > Samuel Thibault wrote: > > And the concurrency-safety of Hurd code has never been tested. Yes, it > > does matter: threaded code can work on UP and fail on SMP because a > > couple of new scheduling scenarii appear and a lot of rare scheduli

Re: What would it take....

Da Zheng, le Tue 22 Dec 2009 22:24:33 +0800, a écrit : > Samuel Thibault wrote: > >> 5. What would it take to implement task #7050? (process-shared > >> semaphores and mutexes) > > > > Good understanding of both the Posix norm and Hurd's RPCs, and careful >

Re: What would it take....

Samuel Thibault wrote: > > And the concurrency-safety of Hurd code has never been tested. Yes, it > does matter: threaded code can work on UP and fail on SMP because a > couple of new scheduling scenarii appear and a lot of rare scheduling > scenarii become common. It's really bad to hear that:-(

Re: What would it take....

Tim Kack, le Tue 22 Dec 2009 15:19:26 +0100, a écrit : > On Tue, 2009-12-22 at 14:51 +0100, Samuel Thibault wrote: > > Tim Kack, le Tue 22 Dec 2009 14:31:46 +0100, a écrit : > > > 2. What would it take to enable Hurd to use >1 Gb of memory > > > > It already

Re: What would it take....

Hi, Tim Kack wrote: >>> 1. What would it take to bring the device driver layer (which is from >>> Linux 2.0 via glue code?) up to either a modern BSD or Linux 2.6 level? >> A lot. See the discussion about the DDE work of Zheng Da for a way to >> deport the work to

Re: What would it take....

Hi, Samuel Thibault wrote: >> 5. What would it take to implement task #7050? (process-shared >> semaphores and mutexes) > > Good understanding of both the Posix norm and Hurd's RPCs, and careful > implementation. Do Hurd's RPCs have to be used in order to provi

Re: What would it take....

On Tue, 2009-12-22 at 14:51 +0100, Samuel Thibault wrote: > Tim Kack, le Tue 22 Dec 2009 14:31:46 +0100, a écrit : > > 1. What would it take to bring the device driver layer (which is from > > Linux 2.0 via glue code?) up to either a modern BSD or Linux 2.6 level? > > A lo

Re: What would it take....

Samuel Thibault, le Tue 22 Dec 2009 14:51:22 +0100, a écrit : > > 3. What would it take to enable SMP and/or NORMA-RPC? > > No real development as GNU Mach is already supposed to be SMP-safe. > Problem is that the drivers are old and don't work with ACPI, BTW, it'd pro

Re: What would it take....

Tim Kack, le Tue 22 Dec 2009 14:31:46 +0100, a écrit : > 1. What would it take to bring the device driver layer (which is from > Linux 2.0 via glue code?) up to either a modern BSD or Linux 2.6 level? A lot. See the discussion about the DDE work of Zheng Da for a way to deport the work to t

What would it take....

1.3.99 for a while: 1. What would it take to bring the device driver layer (which is from Linux 2.0 via glue code?) up to either a modern BSD or Linux 2.6 level? 2. What would it take to enable Hurd to use >1 Gb of memory 3. What would it take to enable SMP and/or NORMA-RPC? 4. What would it t