Re: hurd/trans/hello.c changes

Hi, --- On Thu, Dec 24, 2009 at 12:42 AM, Sergiu Ivanov wrote: | I'd say it would be better if you had just posted the whole set of | your changes as a single patch with the necessary comments, both | because this way your E-mail is ready to be applied as a patch and | because it's less work for

Re: Non-compliant access behavior?

ST> Apparently access() restricts itself to the real gid, without ST> including supplementary group IDs. As IEEE 1003.1:2004 says, at least by omission, it should. There's no mention of supplementary group IDs in the definition of the access() call. This isn't a particularly well-specified aspec

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. > > Doing network-transparent IPC at the mi

SMP, barriers, etc.

(I've cleaned To: and subject a bit :) Da Zheng, le Wed 23 Dec 2009 21:23:23 +0800, a écrit : > 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:) Yes, it's ver

Re: Builds

> Which repositories? > > In principle, Debian packages already follow the Hurd repositories well. > > Actually any official repositories.. i should have asked whether there is an easy way how to make a new disc image build myself (not to wait for L2, as i dont know how long it would take to releas

Re: Builds

Jakub Daniel, le Wed 23 Dec 2009 18:31:29 +0100, a écrit : > is it possible to build Hurd disc images from git repositories? Which repositories? In principle, Debian packages already follow the Hurd repositories well. Samuel

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 don't work with ACPI, and > > > the SMP-

Re: hurd/trans/hello.c changes

Hello, On Wed, Dec 23, 2009 at 10:52:14PM +0530, Shakthi Kannan wrote: > >From git://git.sv.gnu.org/hurd/hurd.git, > > On commit 908ba8441182f34a7b565a692ebb60e8af321d17, some > clarifications on hurd/trans/hello.c: > > 1. version.h is located in /usr/include/hurd/version.h, so hello.c > should

Re: review of modifications of eth-multiplexer

Hello, On Wed, Dec 23, 2009 at 08:42:30AM +0800, Da Zheng wrote: > > How do you get my Hurd.git repository? In it, is there history of > eth-multiplexer development? I don't have any eth-multiplexer > development history in my own git repository. As I said on the IRC, I planned to send you the r

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

Hello, On Wed, Dec 23, 2009 at 08:52:33AM +0800, Da Zheng wrote: > netfs_attempt_lookup locks this node and the node is unlocked by > libnetfs, right? I forget a lot:-) So why can the second lookup not > wait until the first one finishes? I've tried to remove the mutex unlocking code and it seems

Builds

Hello is it possible to build Hurd disc images from git repositories? it would be cool to make one actual image as for example grub2 (installed nativelly) would make every reinstall much easier now. i guess its not easy. Thanks Jakub

hurd/trans/hello.c changes

Hi, >From git://git.sv.gnu.org/hurd/hurd.git, On commit 908ba8441182f34a7b565a692ebb60e8af321d17, some clarifications on hurd/trans/hello.c: 1. version.h is located in /usr/include/hurd/version.h, so hello.c should include? === PATCH === -#include +#include === END === 2. trivfs_modify_sta

Re: review of modifications of eth-multiplexer

Hello, On Wed, Dec 23, 2009 at 03:51:16PM +0100, olafbuddenha...@gmx.net wrote: > On Tue, Dec 22, 2009 at 11:25:51PM +0200, Sergiu Ivanov wrote: > > > but looking at the commit history in your hurd.git repository, I can > > see that there are commits concerning the multiplexer and other parts > >

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. In fa

Re: review of modifications of eth-multiplexer

Hi, On Tue, Dec 22, 2009 at 11:25:51PM +0200, Sergiu Ivanov wrote: > but looking at the commit history in your hurd.git repository, I can > see that there are commits concerning the multiplexer and other parts > of the Hurd (like boot and filter) mingled. These are probably all related. It's all

Re: [RFC] git fs translator

Hi, On Wed, Dec 23, 2009 at 01:08:50AM +0100, Thomas Schwinge wrote: > Isn't Git implemented in terms of an (internal?) library like libgit > (or similar), these days? I don't think so... Even if it is, it definitely doesn't have a stable and/or public API. The command line is the API -- that's

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 Linux 2.0 via glue code?) up to e

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

Hurd on Qemu-Message6-Bug-hurd Digest, Vol 85, Issue 22

Hi, >How to make apt-get on hurd inside Qemu working with proxy. >The host system is behind a proxy. Run the following to apt-get work if you are behind proxy #http_export=http://[uname]:[passwo...@proxy address:port #http_export=http://[uname]:[passwo...@proxy adress:port

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: review of modifications of eth-multiplexer

Hi, On Tue, Dec 22, 2009 at 07:51:35PM +0800, Da Zheng 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

Re: [RFC] git fs translator

Hi, On Sun, Dec 20, 2009 at 02:49:19PM +0530, Shakthi Kannan wrote: > The idea is to write a simple translator that can query results from a > remote git repository. The "remote repository" part really makes it tricky. I'm not aware of any public API in Git that allows fetching individual object

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