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: [RFC] git fs translator

Hi, --- On Wed, Dec 23, 2009 at 5:38 AM, Thomas Schwinge wrote: | That's the one to use.  Here is a tutorial for libnetfs: | . \-- Thanks. --- | Isn't Git implemented in terms of an (internal?) library like libgit (or | similar), these days?

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: [PATCH 2/2] Setup the node stat information in netfs_validate_stat.

Sergiu Ivanov wrote: > Hello, > > On Tue, Dec 22, 2009 at 07:40:12PM +0800, Da Zheng wrote: >> Could you tell me why initializing node status here is perferred? > > The multiplexer creates nodes on any demand, whether the client > intends to further use the node to create a (virtual) device or no

Re: [PATCH] Add the .MASTER node to the eth-multiplexer.

Sergiu Ivanov wrote: > Hello, > > On Tue, Dec 22, 2009 at 07:37:21PM +0800, Da Zheng wrote: >> Sergiu Ivanov wrote: >>> @@ -85,6 +89,18 @@ new_node (struct lnode *ln, struct node **np) >>> struct node * >>> lookup (char *name) >>> { >>> + if (strcmp(name, MASTER_NODE_NAME) == 0) >>> +{ >>>

Re: review of modifications of eth-multiplexer

Hi, Sergiu Ivanov wrote: >> Can you push eth-multiplexer to incubator? If you do so, will you >> have its development history? > > Hm, I'm afraid my answer will be negative :-( True, I have pushed a > project to the incubator with Thomas's detailed help, but looking at > the commit history in you

[bug #28383] Non-compliant access behavior?

URL: Summary: Non-compliant access behavior? Project: The GNU Hurd Submitted by: sthibaul Submitted on: mer 23 déc 2009 01:10:51 CET Category: None Severity: 3 - Norma

Re: [RFC] git fs translator

Hello! On Sun, Dec 20, 2009 at 02:49:19PM +0530, Shakthi Kannan wrote: > This is in regard to a prototype implementation of gitfs translator > for a student project. The idea is to write a simple translator that > can query results from a remote git repository. > > * Which lib*fs translator can b

Re: review of modifications of eth-multiplexer

Hello, On Tue, Dec 22, 2009 at 07:51:35PM +0800, Da Zheng wrote: > Sergiu Ivanov wrote: > > > > You can find the patches in the bug-hurd mailing list archives: > > > > http://lists.gnu.org/archive/html/bug-hurd/2009-08/msg00056.html > > http://lists.gnu.org/archive/html/bug-hurd/2009-08/msg00053

Re: [PATCH 2/2] Setup the node stat information in netfs_validate_stat.

Hello, On Tue, Dec 22, 2009 at 07:40:12PM +0800, Da Zheng wrote: > Could you tell me why initializing node status here is perferred? The multiplexer creates nodes on any demand, whether the client intends to further use the node to create a (virtual) device or not. This means that, for instance,

Re: [PATCH] Add the .MASTER node to the eth-multiplexer.

Hello, On Tue, Dec 22, 2009 at 07:37:21PM +0800, Da Zheng wrote: > Sergiu Ivanov wrote: > > @@ -85,6 +89,18 @@ new_node (struct lnode *ln, struct node **np) > > struct node * > > lookup (char *name) > > { > > + if (strcmp(name, MASTER_NODE_NAME) == 0) > > +{ > > + netfs_nref (master_n

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 > > implementation. > Do Hurd's RPCs have

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 does since a recent commit. We're stil

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 the DDE community. > > Thanks fo

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 provide process-shared semaphores? I thou

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 lot. See the discussion ab

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 probably be easier to tackle th

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 the DDE

What would it take....

Hi, First disclaimer - the content of this email might have been discussed before so please bear with me. Second disclaimer - I do not argue whether GNU/Hurd should use a different kernel or not (L4 derivate or not, Viengoos or Coyotos etc) in the future. I have been following the Hurd project f

Hurd on Qemu

Hi, How to make apt-get on hurd inside Qemu working with proxy. The host system is behind a proxy.

Re: review of modifications of eth-multiplexer

Hi, Sergiu Ivanov wrote: > > You can find the patches in the bug-hurd mailing list archives: > > http://lists.gnu.org/archive/html/bug-hurd/2009-08/msg00056.html > http://lists.gnu.org/archive/html/bug-hurd/2009-08/msg00053.html I think your patch is good:-) > > I've created two patch series in

Re: [PATCH 2/2] Setup the node stat information in netfs_validate_stat.

Hi, Sergiu Ivanov wrote: > diff --git a/eth-multiplexer/device_impl.c b/eth-multiplexer/device_impl.c > index 4b2d37d..abbd146 100644 > --- a/eth-multiplexer/device_impl.c > +++ b/eth-multiplexer/device_impl.c > @@ -98,8 +98,6 @@ ds_device_open (mach_port_t master_port, mach_port_t > reply_port,

Re: [PATCH] Add the .MASTER node to the eth-multiplexer.

Hi, Sergiu Ivanov wrote: > diff --git a/eth-multiplexer/netfs_impl.c b/eth-multiplexer/netfs_impl.c > index c70701b..875ff48 100644 > --- a/eth-multiplexer/netfs_impl.c > +++ b/eth-multiplexer/netfs_impl.c > @@ -31,6 +31,10 @@ > #include "vdev.h" > #include "util.h" > > +/* The .MASTER node wh

FOSDEM 2010

Hello! FOSDEM 2010 is slowly approaching. A few Hurd types have shown interest in meeting there, so I created for coordination. Beware that web-editing (and the whole of bddebian HTTP) is still down due to this