Re: [task #6537] Implement ddb/db_elf.c

Andrei Barbu, le Tue 27 May 2008 19:02:18 +, a écrit : > Additional Item Attachment, task #6537 (project hurd): > > File name: changelog-elf-1.patch Size:1 KB Ok, you make the same mistake as I did some time ago when I started working on GNU projects :) GNU style changelog are not a

Re: [Hurd] error_t, E*, and c++

Hmm. You need at least "#define EFOO EFOO" to make "#ifdef EFOO" work. But one of the reasons for the current style of definition is in particular so that "#if EAGAIN != EWOULDBLOCK" works right. That can only win if it's a cpp-interpretable expression, which cannot use enum constants or syntax l

Re: [task #6537] Implement ddb/db_elf.c

Hello, Looks good (quite straight forward actually), except the coding style of db_elf.c. It'd be good to keep the same as db_aout.c for instance, for at least local style coherency :) Samuel

Revision control

Hi, Would there be support for moving to a different revision control mechanism? Anything is far better than cvs, especially if it's distributed. I saw there was some talk of this a while ago but nothing happened. We've got lots of good options to pick from that we know will scale well. Andrei

[task #6537] Implement ddb/db_elf.c

Additional Item Attachment, task #6537 (project hurd): File name: changelog-elf-1.patch Size:1 KB ___ Reply to this item at: ___ Message sent

[task #6537] Implement ddb/db_elf.c

Follow-up Comment #2, task #6537 (project hurd): Updated the reflect the discussion on bug-hurd. (file #15746) ___ Additional Item Attachment: File name: elf-1.patchSize:71 KB

Re: Namespace-based translator selection; project details

Hello, On Mon, May 26, 2008 at 8:49 PM, <[EMAIL PROTECTED]> wrote: > As I already suggested, at least for the prototype, I believe it can be > implemented as a proxy which mirrors the underlying file system, and > does it's magic whenever a virtual file with the special suffix is > accessed. > >

Re: dtrace/systemtap options

Hello, Andrei Barbu, le Mon 26 May 2008 17:57:04 -0400, a écrit : > On Mon, May 26, 2008 at 5:27 PM, Samuel Thibault > > BTW, I'm not sure to understand: what does RW means? Being able to > > tinker with kernel parameters? > > > > Yup, you could potentially do so in both dtrace and systemtap; >

Re: [Hurd] error_t, E*, and c++

Samuel Thibault, le Tue 27 May 2008 11:01:29 +0100, a écrit : > Roland McGrath, le Mon 26 May 2008 20:01:17 -0700, a écrit : > > But I think we might just have to live with > > C++ using (error_t) EFOO, > > A friend of mine suggested to rather use error_t(EFOO), which is a bit > less dirty but sti

Re: [Hurd] error_t, E*, and c++

Roland McGrath, le Mon 26 May 2008 20:01:17 -0700, a écrit : > But I think we might just have to live with > C++ using (error_t) EFOO, A friend of mine suggested to rather use error_t(EFOO), which is a bit less dirty but still works. > or else supply a C++ or whatever where there is explicitly >

Re: [Hurd] error_t, E*, and c++

Roland McGrath, le Mon 26 May 2008 20:01:17 -0700, a écrit : > (The error_t usage being broken in C++ is at least not a silent change > or breakage of something that already works.) True for us, but it does work on e.g. Linux since error_t is typedefed to int there :/ > It may also be a problem i