Re: GSoC meetings

On Fri, Aug 27, 2010 at 01:51:09AM +0200, Emilio Pozuelo Monfort wrote: > On 22/08/10 11:18, olafbuddenha...@gmx.net wrote: > > I guess we will soon need to come up with a new meeting schedule, now > > that the summer session is almost over: go back to meeting once a week; > > and probably account

Re: GSoC meetings

Hi, On Sun, Aug 22, 2010 at 11:18:41AM +0200, olafbuddenha...@gmx.net wrote: > > First of all, I'm not sure I will be able to make it to the meeting > tomorrow. (Am at FrOSCon right now :-) ) But as usual, that shouldn't > stop the others from meeting. Sure, have a good time. :-) > I guess we

Re: [PATCH 2/8] Avoid hashing garbage for short keynames.

Hi, On Wed, Aug 11, 2010 at 07:04:17PM -0300, Diego Nieto Cid wrote: > Hi, > > 2010/8/9 : > > > > Hm, why tmp[5]? The way I read the code, only 4 entries are used... > > > > Well it's the null that terminates the string. But as this isn't used > as a string it probably does not make much sense.

Re: Fixing grub-probe to work with user-space part stores

Hi, On Tue, Jul 27, 2010 at 08:22:14PM +0200, olafbuddenha...@gmx.net wrote: > On Wed, Jul 14, 2010 at 07:51:07PM +0200, Carl Fredrik Hammar wrote: > > On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote: > > > > The first one would be to make part.c embed ext

Re: [PATCH] Add support to send file descriptors over Unix sockets

Hi, On Tue, Jul 27, 2010 at 08:08:36PM +0200, Emilio Pozuelo Monfort wrote: > > This patch adds support for SCM_RIGHTS to glibc. It works fine > when sending file descriptors from a socket() or a socketpair() call, > but not from e.g. an open() call, as I've mentioned in another mail. > That's no

Re: [PATCH 3/3] Use the new _hurd_exec_file_name function

Hi, On Mon, Jul 26, 2010 at 07:33:58PM +0200, Emilio Pozuelo Monfort wrote: > >From c6276e2df1d370dbbdd7f4e6fb388f241f84fee7 Mon Sep 17 00:00:00 2001 > From: Emilio Pozuelo Monfort > Date: Wed, 26 May 2010 23:32:16 +0200 > Subject: [PATCH 3/3] Use the new _hurd_exec_file_name function > > * conf

Re: exec server and /dev/fd/N

Hi, On Mon, Jul 26, 2010 at 07:28:42PM +0200, Emilio Pozuelo Monfort wrote: > New iteration. All mentioned issues have been fixed, except for the glibc > check > for the file_exec_file_name RPC, which I don't know how to do if not using > HURD_INTERFACE_VERSION. Any suggestions are welcome. I ha

Re: [PATCH] Use the new file_exec_file_name RPC

Hi, On Mon, Jul 26, 2010 at 07:42:25PM +0200, Emilio Pozuelo Monfort wrote: > Also I've tested with the Debian package (which is at 2.11.2) so I > needed to change the Versions file. I changed it to 2.11.2, but I > got quite some warnings that GLIBC_2_11_2 was undefined. I changed > it to 2_11 and

Re: [PATCH 2/3] Add a file_exec_file_name RPC

Hi, On Mon, Jul 26, 2010 at 07:32:04PM +0200, Emilio Pozuelo Monfort wrote: > @@ -159,14 +193,28 @@ diskfs_S_file_exec (struct protid *cred, >do > { > right = ports_get_send_right (newpi); > - err = exec_exec (execserver, > -right, MACH_MSG_TYPE_

Re: [PATCH] pfinet: check return value of mmap() in S_io_read() and S_socket_recv()

Hi, On Thu, Jul 22, 2010 at 12:16:08PM +0200, olafbuddenha...@gmx.net wrote: > I realized that my problems with pfinet crashing after apt-get fetching > ~90 MB of packages, are due to a gaping virtual memory leak in pfinet. > (Probably the same one Samuel fixed recently; but I haven't tested his >

Re: [PATCH] Use the new __hurd_exec_file_name RPC

Hi, On Sat, Jul 17, 2010 at 02:07:19PM +0200, Guillem Jover wrote: > On Fri, 2010-07-16 at 12:21:16 +0200, Emilio Pozuelo Monfort wrote: > > And here goes the glibc one. > > > diff --git a/hurd/hurd.h b/hurd/hurd.h > > index 642ea43..a83c3fa 100644 > > --- a/hurd/hurd.h > > +++ b/hurd/hurd.h > >

Re: [PATCH] Bump HURD_INTERFACE_VERSION

On Fri, Jul 16, 2010 at 12:19:21PM +0200, Emilio Pozuelo Monfort wrote: > >From 03b291be17be4beb67d7397526c1ae7c292649df Mon Sep 17 00:00:00 2001 > From: Emilio Pozuelo Monfort > Date: Thu, 15 Jul 2010 20:37:20 +0200 > Subject: [PATCH] Bump HURD_INTERFACE_VERSION > > * hurd/version.h (HURD_

Re: [PATCH] Use the new __hurd_exec_file_name RPC

On Fri, Jul 16, 2010 at 12:21:16PM +0200, Emilio Pozuelo Monfort wrote: > And here goes the glibc one. > > Regards, > Emilio > > 2010-07-16 Emilio Pozuelo Monfort > * hurd/hurdexec.c (_hurd_exec): Deprecate it. > (_hurd_exec_file_name): New function. > * hurd/hurd.h: Declare

Re: [PATCH 3/3] Use the new _hurd_exec_file_name function

On Fri, Jul 16, 2010 at 12:17:38PM +0200, Emilio Pozuelo Monfort wrote: > Note that this patch should only be applied after the glibc patch is applied, > and maybe some time later (perhaps after a stable release shipping it?). I think the commit order will need to be brought up at today's meeting.

Re: [PATCH 2/3] Add a file_exec_file_name RPC

On Fri, Jul 16, 2010 at 12:15:06PM +0200, Emilio Pozuelo Monfort wrote: > >From 3804a36fcf95a3fd588ce67a08a36346134b8d1f Mon Sep 17 00:00:00 2001 > From: Emilio Pozuelo Monfort > Date: Wed, 26 May 2010 01:27:40 +0200 > Subject: [PATCH 2/3] Add a file_exec_file_name RPC > > * hurd/fs.defs (f

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

Hi, On Fri, Jul 16, 2010 at 12:13:56PM +0200, Emilio Pozuelo Monfort wrote: > On 31/05/10 18:27, Carl Fredrik Hammar wrote: > > I have reviewed the patches and apart from formatting there were only > > a couple of issues. Next iteration is hopefully the last. > > I hope s

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

On Sat, Jul 17, 2010 at 03:36:43PM +0200, Ludovic Courtès wrote: > Emilio Pozuelo Monfort writes: > > > error_t > > S_socket_getopt (struct sock_user *user, > > int level, int opt, > > char **value, size_t *value_len) > > { > > - return EOPNOTSUPP; > > + int ret = 0

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

On Sat, Jul 17, 2010 at 12:25:48PM +0200, Carl Fredrik Hammar wrote: > Hi, > > On Sat, Jul 17, 2010 at 11:37:34AM +0200, Emilio Pozuelo Monfort wrote: > > + *(int*)*value = user->sock->pipe_class->sock_type; > > + *value_len = sizeof (int); > > + b

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

Hi, On Sat, Jul 17, 2010 at 11:37:34AM +0200, Emilio Pozuelo Monfort wrote: > On 15/07/10 20:46, Carl Fredrik Hammar wrote: > > On Thu, Jul 15, 2010 at 05:15:25PM +0200, Emilio Pozuelo Monfort wrote: > > The first thing you should do in any RPC that is not a stub is:

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

Hi, On Thu, Jul 15, 2010 at 05:15:25PM +0200, Emilio Pozuelo Monfort wrote: > On 15/07/10 17:05, Emilio Pozuelo Monfort wrote: > > On 15/07/10 16:49, Emilio Pozuelo Monfort wrote: > >> Here it goes, with a good commit message: > > > > Forgot to add the file before committing :( > > Also check th

Re: Fixing grub-probe to work with user-space part stores

Hi, On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote: > The first one would be to make part.c embed extra information in its > stores and their encoded form (possibly in the "misc" fiels of a remap > store). This would force it to create a new layer instead of reusing > the underlyin

Re: hurdextras in git?

Hi, On Tue, Jul 13, 2010 at 03:23:51AM +0200, Arne Babenhauserheide wrote: > > > They have some very interesting translators, and these should be easily > > > available. > > > And easily doesn’t mean cvs :) > > > > Yeah, definitaly. > > Should all be in one repository with different subfolders o

Re: hurdextras in git?

Hi, On Mon, Jul 12, 2010 at 03:24:53PM +0200, Arne Babenhauserheide wrote: > Are the hurdextras already in git? No, only unionfs: . > They have some very interesting translators, and these should be easily > available. > > And easily doesn’

Re: What do you need from the Hurd for your day-to-day tasks?

On Mon, Jul 12, 2010 at 08:41:49AM +0200, Arne Babenhauserheide wrote: > What is missing for you? Sound support, wireless, and PPPoE. I could probably factor out these to a seperate router/sound box but at that point I might as well just run Hurd in in kvm and use the host as the support box, wh

Re: Reauthentication EINTR bug

On Mon, Jul 05, 2010 at 01:23:15PM -0700, Roland McGrath wrote: > > This would be ideal, but my current understanding is that > > interrupt_operation() is mostly advisory and that the operation will > > restart or return EINTR regardless of what the server does, and if this > > is true then it is i

Re: Reauthentication EINTR bug

Hi, On Sun, Jul 04, 2010 at 12:34:19PM -0700, Roland McGrath wrote: > The auth server, like any server handling interrupt_operation, is > responsible for making sure that the operation either is entirely > interrupted cleanly, or completes normally. For the auth handshake, > interrupting cleanly

Reauthentication EINTR bug

Hello, I have been investigating the EINTR bug for a while now, and I'm finally confident about what the problem is. As a reminder, the bug causes sudo to sometimes fail with EPERM, usually when it tries to open /etc/sudoers because a reauthentication has failed silently. While we originally tho

Re: News 2010-06

Hi, On Sat, Jul 03, 2010 at 04:11:37PM +0200, Thomas Schwinge wrote: > > What's the status of the other GSoC projects? Well, progress on the test cases have ground to a halt the last couple of weeks due to exams. However, progress up to the exam period was good, and Emilio will be back late next

Re: preliminary patch for initrd support in Mach

On Mon, Jun 14, 2010 at 10:49:42AM +0200, Samuel Thibault wrote: > Carl Fredrik Hammar, le Mon 14 Jun 2010 10:47:15 +0200, a écrit : > > > > Is there such a thing as a task ID though? I thought tasks can only > > referenced by ports? > > Replace "task id&quo

Re: preliminary patch for initrd support in Mach

On Mon, Jun 14, 2010 at 10:33:49AM +0200, Samuel Thibault wrote: > Carl Fredrik Hammar, le Mon 14 Jun 2010 10:22:26 +0200, a écrit : > > (For instance, it might be possible to make Mach create a task without > > thread if it can't execute the image, then you could just read th

Re: preliminary patch for initrd support in Mach

Hi, On Mon, Jun 14, 2010 at 09:00:05AM +0200, olafbuddenha...@gmx.net wrote: > > or that modifying Mach for this purpose is misguided and should be > > avoided (for instance by embedding the initrd in a dedicated section > > of an elf module). > > Hm... I don't remember this variont actually bein

[bug #30096] ext2fs leaks memory on multiple execs from same process

Follow-up Comment #2, bug #30096 (project hurd): Ports are leaked on execve(), most likely in the exec server. If any of these ports goes to ext2fs, this would explain this bug. I have attached a program which prints the number of leaks (7). (file #20726) _

[bug #30096] ext2fs leaks memory on multiple execs from same process

Follow-up Comment #1, bug #30096 (project hurd): As suggested by antrik, the number of threads also explodes when you kill the execing process. Perhaps the increase in memory usage is because of this. Also, I did a quick check to see if Sergio's sync patches magically fixes this, but they did n

[bug #30096] ext2fs leaks memory on multiple execs from same process

URL: Summary: ext2fs leaks memory on multiple execs from same process Project: The GNU Hurd Submitted by: hammy Submitted on: Wed 09 Jun 2010 04:15:13 PM CEST Category: Hurd

Re: [PATCH] tmpfs: add padding to tmpfs_dirent structure

On Thu, May 20, 2010 at 12:18:44AM +0200, Sergio Lopez wrote: > El Wed, 19 May 2010 23:32:37 +0200 > Samuel Thibault escribió: > > > Sergio Lopez, le Wed 19 May 2010 17:33:39 +0200, a écrit : > > > El Wed, 19 May 2010 16:05:27 +0200 > > > Carl Fredrik Hammar esc

[PATCH] Fix malloc size in tmpfs

* tmpfs/dir.c (diskfs_direnter_hard): Fix malloc size. --- Hello, Found this little doozy while examining Sergio's patches. ENTSIZE was changed back in 2f7f90ce to reflect the size of a struct dirent instead of a tmpfs_dirent, but NEW is still a tmpfs_dirent... I just snatched the old code prio

[PATCH] Check for null ports in auth server

* auth/auth.c (S_auth_user_authenticate, S_auth_server_authenticate): Fail with EINVAL if RENDEZVOUS is MACH_PORT_NULL. --- Hi, This patch makes the auth server fail with EINVAL if the rendezvous port is null. I don't really think this needs much motivation but then again I also didn't think the

Re: [PATCH] Check for rendezvous port death in auth server

Hi, On Thu, Jun 03, 2010 at 06:55:12AM +0200, olafbuddenha...@gmx.net wrote: > On Wed, Jun 02, 2010 at 06:35:02PM +0200, Carl Fredrik Hammar wrote: > > On Wed, Jun 02, 2010 at 12:17:12AM +0200, olafbuddenha...@gmx.net > > wrote: > > > > I'm a bit ambivalent abou

Re: [PATCH] Check for rendezvous port death in auth server

Hi, On Wed, Jun 02, 2010 at 12:17:12AM +0200, olafbuddenha...@gmx.net wrote: > > I'm a bit ambivalent about this... On one hand, returning the right > error code right away is probably less confusing; but on the other hand, > it adds extra code paths (with all the associated disadvantages) for >

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

Hi, On Wed, Jun 02, 2010 at 12:00:13AM +0200, olafbuddenha...@web.de wrote: > Keep in mind that this convention stems from a time where people > actually used to *print* code, on a 80 column line printer... So it was > important to strictly observe the limit back then. Nowadays, screens are > larg

[PATCH] Check for rendezvous port death in auth server

* auth/auth.c (S_auth_user_authenticate,S_auth_server_authenticate): Return EINVAL if rendezvous port dies during transaction. --- Hello, This is a patch for the auth server to make it also return EINVAL when the rendezvous port has died during a transaction and not only if it is dead on arrival,

Re: [PATCH] Use the new __hurd_exec_file_name RPC

Hi, On Tue, Jun 01, 2010 at 03:50:26AM +0200, olafbuddenha...@gmx.net wrote: > On Mon, May 31, 2010 at 06:16:06PM +0200, Carl Fredrik Hammar wrote: > > On Sat, May 22, 2010 at 06:26:29PM +0200, Emilio Pozuelo Monfort wrote: > > > > + err = __file_exec_file_na

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

Hi, On Tue, Jun 01, 2010 at 03:52:59AM +0200, olafbuddenha...@gmx.net wrote: > On Mon, May 31, 2010 at 05:59:09PM +0200, Carl Fredrik Hammar wrote: > > On Wed, May 26, 2010 at 12:15:37AM +0200, Emilio Pozuelo Monfort wrote: > > > > +kern_return_t > > >

Re: exec server and /dev/fd/N

Hi, On Mon, May 31, 2010 at 06:27:29PM +0200, Carl Fredrik Hammar wrote: > > Regarding version.h, I've bumped HURD_INTERFACE_VERSION in 0001 for > > exec_exec_file_name, but should it be bumped in 0002 too? > > This sounds good to me but if someone else objects you sh

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

On Wed, May 26, 2010 at 12:15:37AM +0200, Emilio Pozuelo Monfort wrote: > diff --git a/exec/exec.c b/exec/exec.c > index 272b789..6b0f721 100644 > --- a/exec/exec.c > +++ b/exec/exec.c > @@ -1,5 +1,5 @@ > /* GNU Hurd standard exec server. > - Copyright (C) 1992,93,94,95,96,98,99,2000,01,02,04 >

Re: exec server and /dev/fd/N

Hi, I have reviewed the patches and apart from formatting there were only a couple of issues. Next iteration is hopefully the last. On Thu, May 27, 2010 at 06:22:26PM +0200, Emilio Pozuelo Monfort wrote: > On 25/05/10 21:10, Carl Fredrik Hammar wrote: > > It would also be good if y

Re: [PATCH] Use the new __hurd_exec_file_name RPC

Hi, On Sat, May 22, 2010 at 06:26:29PM +0200, Emilio Pozuelo Monfort wrote: > diff --git a/hurd/Versions b/hurd/Versions > index 83c8ab1..81cd904 100644 > --- a/hurd/Versions > +++ b/hurd/Versions > @@ -73,6 +73,7 @@ libc { > _hurd_critical_section_unlock; > _hurd_exception2signal; >

Re: [PATCH 3/3] Use the new _hurd_exec_file_name function

Hi, On Wed, May 26, 2010 at 11:32:16PM +0200, Emilio Pozuelo Monfort wrote: > diff --git a/utils/fakeauth.c b/utils/fakeauth.c > index 49fa7f1..ccc0855 100644 > --- a/utils/fakeauth.c > +++ b/utils/fakeauth.c > @@ -1,5 +1,5 @@ > /* fakeauth -- proxy auth server to lie to users about what their ID

Re: [PATCH 2/3] Add a file_exec_file_name RPC

Hi, On Wed, May 26, 2010 at 01:27:40AM +0200, Emilio Pozuelo Monfort wrote: > diff --git a/exec/hashexec.c b/exec/hashexec.c > index 6be8dfe..c2d0f7d 100644 > --- a/exec/hashexec.c > +++ b/exec/hashexec.c > @@ -420,15 +420,28 @@ check_hashbang (struct execdata *e, > return; > >/* Execut

Re: [PATCH] Fix --version in scripts

Hi! On Wed, May 26, 2010 at 07:07:54PM +0200, Thomas Schwinge wrote: > > I'm totally fine with patches being checked in after there's some > consensus that they are what we want. This applies to this easy one, but > likewise applies to those that Sergio has posted, for example. Sounds good! >

Re: exec server and /dev/fd/N

Hi, On Tue, May 25, 2010 at 09:10:57PM +0200, Carl Fredrik Hammar wrote: > On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote: > > > > diff --git a/exec/hashexec.c b/exec/hashexec.c > > index 2aa3844..7a7b329 100644 > > --- a/exec/hashexec.

Re: [PATCH] Fix --version in scripts

Hi, On Wed, May 26, 2010 at 10:25:49AM +0200, olafbuddenha...@gmx.net wrote: > On Tue, May 25, 2010 at 10:49:16AM +0200, Carl Fredrik Hammar wrote: > > > Emilio reported that `fakeroot --version' (fakeroot-hurd in Debian) > > prints out `STANDARD_HURD_VERSION_uptime_'

Re: exec server and /dev/fd/N

On Wed, May 26, 2010 at 09:42:05AM +0200, olafbuddenha...@gmx.net wrote: > > I've commented on every hunk to make sure I looked through it all, > > which makes it a bit long but hopefully easy to follow (complain if it > > isn't). > > Well, it certainly does make it pretty redundant... I prioriti

Re: exec server and /dev/fd/N

On Wed, May 26, 2010 at 12:29:06PM +0200, Emilio Pozuelo Monfort wrote: > On 26/05/10 09:32, olafbuddenha...@gmx.net wrote: > > On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote: > > > >> Basically the problem is that in some cases the exec server can't find > >> the file name

Re: exec server and /dev/fd/N

Hi, On Tue, May 25, 2010 at 11:03:43PM +0200, Emilio Pozuelo Monfort wrote: > > The first three patches are pretty useless on their own, they all affect > > the same program, and most changes are pretty mechanical, so I think > > you might as well merge them. > > OK. I thought about going step by

Re: exec server and /dev/fd/N

On Wed, May 26, 2010 at 01:39:24AM +0200, Emilio Pozuelo Monfort wrote: > On 25/05/10 21:10, Carl Fredrik Hammar wrote: > >> @@ -278,7 +280,9 @@ check_hashbang (struct execdata *e, > >> else > >>name = argv; > >> > >> -

Re: exec server and /dev/fd/N

On Tue, May 25, 2010 at 11:30:07PM +0200, Samuel Thibault wrote: > Emilio Pozuelo Monfort, le Tue 25 May 2010 23:03:43 +0200, a écrit : > > > Oh, I haven't noticed this file before. :-) > > > > It's the list of symbols libc.so should export. Since _hurd_exec is a public > > API, I guessed _file_n

Re: exec server and /dev/fd/N

Hi, On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote: > > These are a series of patches to fix https://savannah.gnu.org/bugs/?28934 > > Basically the problem is that in some cases the exec server can't find the > file > name of the file being executed (when it's a script),

[PATCH] Fix --version in scripts

Hi, Emilio reported that `fakeroot --version' (fakeroot-hurd in Debian) prints out `STANDARD_HURD_VERSION_uptime_' instead of its version. The bug is due to a faulty make rule which depends on the original sed script which inserted the correct version but was later inlined into Makeconf itself (ba

Re: [PATCH] tmpfs: add padding to tmpfs_dirent structure

On Tue, May 18, 2010 at 05:36:19PM +0200, Sergio Lopez wrote: > El Tue, 18 May 2010 16:33:59 +0200 > Carl Fredrik Hammar escribió: > > along with another one that fixes symlinks. Perhaps you could adopt > > that patch as well and try to get it checked in since you're alrea

Re: [PATCH] tmpfs: add padding to tmpfs_dirent structure

On Tue, May 18, 2010 at 04:19:34PM +0200, Sergio Lopez wrote: > > This patch adds some padding to tmpfs_dirent structure as it's > suggested in the wiki > (http://www.gnu.org/software/hurd/hurd/translator/tmpfs.html). > It seems Samuel beat you to it back in January: see commit 97c569. Regards,

[bug #29914] *_reply.defs can't handle error replies due to type checks

URL: Summary: *_reply.defs can't handle error replies due to type checks Project: The GNU Hurd Submitted by: hammy Submitted on: Wed 19 May 2010 02:05:14 PM CEST Category: GNU MIG

Re: [PATCH] tmpfs: add padding to tmpfs_dirent structure

Hi, On Tue, May 18, 2010 at 04:19:34PM +0200, Sergio Lopez wrote: > This patch adds some padding to tmpfs_dirent structure as it's > suggested in the wiki > (http://www.gnu.org/software/hurd/hurd/translator/tmpfs.html). > > > diff -du hurd-deb.orig/tmpfs/tmpfs.h hurd/tmpfs/tmpfs.h > --- hurd-deb.

[bug #29809] creating a firmlink loop results in memory exhaustion

Follow-up Comment #2, bug #29809 (project hurd): Here is what happens with a settrans -ac foo; ls foo: 0 Client does a dir_lookup("foo") on CWD, presumably on ext2fs 0 ext2fs does a fsys_getroot() on firmlink 0 firmlink does a dir_lookup("foo") on (same) CWD 0 Back to (2) The important bit is t

[bug #29655] linkat() fails because __file_name_lookup_at() problems

Follow-up Comment #4, bug #29655 (project hurd): This has already been said on IRC but I might as well repeat it here: POSIX.1-2008 says that only `AT_SYMLINK_FOLLOW` is applicable to linkat() (see http://www.opengroup.org/onlinepubs/9699919799/functions/linkat.html). I would recommend testing it

[bug #29655] linkat() fails because __file_name_lookup_at() problems

Follow-up Comment #2, bug #29655 (project hurd): The patch looks good, but I do have two minor suggestions. First, I found the comment a bit confusing. The "default" behavior is determined by the O_NOLINK flag, and isn't something that is constant. So perhaps you could change it to mention this

[bug #29642] gdb: breakpoints in triggered in other threads result in SIGTRAP

Follow-up Comment #2, bug #29642 (project hurd): Yes, it is reproducible with cthreads. In fact, I encountered the bug while debugging a cthreads program. (I knew I forgot to mention something...) I just now also confirmed that it is reproducible with a minimal example to make sure it wasn't som

[bug #29642] gdb: breakpoints in triggered in other threads result in SIGTRAP

URL: Summary: gdb: breakpoints in triggered in other threads result in SIGTRAP Project: The GNU Hurd Submitted by: hammy Submitted on: Thu 22 Apr 2010 04:38:30 PM CEST Category: None

Re: Many questions about translators

Hello, On Tue, Apr 20, 2010 at 08:49:16AM +0200, olafbuddenha...@gmx.net wrote: > > > > I'm still not convinced that this is a good idea in general. Private > > > namespaces always make things somewhat intransparent IMHO. > > > > I agree, unless perhaps it is obviously private, e.g. /proc/self.

Re: Many questions about translators

Hello, On Sun, Apr 18, 2010 at 04:27:28AM +0200, olafbuddenha...@gmx.net wrote: > > Nah, I think you are right. Systems that provide private namespaces > (beyond chroot) -- which most notably includes Plan9, but also Linux > nowadays -- do so per-process rather than per-user. So a user gets a > p

Re: Many questions about translators

Hello, On Sun, Apr 18, 2010 at 04:17:17AM +0200, olafbuddenha...@gmx.net wrote: > On Fri, Apr 16, 2010 at 11:52:04AM +0200, Carl Fredrik Hammar wrote: > > > Yes, a translator can attach itself to multiple nodes, but if a > > translator takes an active role in attaching itsel

Re: Many questions about translators

Hi, On Sat, Apr 17, 2010 at 10:54:37AM +0200, Patrik Olsson wrote: > On Fri, 2010-04-16 at 11:52 +0200, Carl Fredrik Hammar wrote: > > On Thu, Apr 15, 2010 at 10:47:49PM +0200, Patrik Olsson wrote: > > > 3. Is it possible to have one translator working on two nodes at >

Re: Many questions about translators

On Fri, Apr 16, 2010 at 01:59:16PM +0200, Samuel Thibault wrote: > Carl Fredrik Hammar, le Fri 16 Apr 2010 11:52:04 +0200, a écrit : > > > 2. If yes on question 1, would this be insecure? For example, if > > > the user overrides a library used by a

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #12, bug #28934 (project hurd): The patch looks good, but I have a couple of suggestions. In __execve you cannot just call _hurd_exec_file_name unconditionally since all exec() variants end up as a __execve(). For instance, if there is both `/bin/foo' and `./foo', execpv("foo"

Re: Many questions about translators

Hello, On Thu, Apr 15, 2010 at 10:47:49PM +0200, Patrik Olsson wrote: > To design HPM (Hurd Package Manager) I need answers to the following > questions (at least to begin with): > > 1. Is it possible for an unprivileged user to override the > translator of a node with another transl

Re: ports_create_port() with bogus size?

Hello, On Mon, Apr 12, 2010 at 01:45:50PM +0200, olafbuddenha...@gmx.net wrote: > > (I guess it *might* make sense to special-case a "0" size, if the caller > simply > is not interested in any additional data -- though I'm not sure that's ever > useful. But other cases are definitely bogus.) It

Re: GSoC: Call for mentors

Hello, On Sun, Apr 11, 2010 at 11:01:20PM +0200, Arne Babenhauserheide wrote: > Am Samstag, 10. April 2010 09:49:02 schrieb olafbuddenha...@gmx.net: > > Now we need to find mentors. So far only Samuel and me have signed up > > for some of the projects; but in case we get more than one slot, it is

Re: GSoC: Call for mentors

On Sat, Apr 10, 2010 at 12:35:32PM +0200, Carl Fredrik Hammar wrote: > On Sat, Apr 10, 2010 at 09:49:02AM +0200, olafbuddenha...@gmx.net wrote: > > > > So please sign up as a mentor for the GNU organisation at > > > >http://socghop.appspot.com/gsoc/mentor/request

Re: GSoC: Call for mentors

Hi, On Sat, Apr 10, 2010 at 09:49:02AM +0200, olafbuddenha...@gmx.net wrote: > > So please sign up as a mentor for the GNU organisation at > >http://socghop.appspot.com/gsoc/mentor/request/google/gsoc2010/gnuproject > > and sign up for those projects you would feel comfortable mentoring :-)

[PATCH 2/2] Implement settrans --interactive

Hello, this patch adds a new option to settrans: --interactive. The main use case is to be able to start a translator under gdb like so: settrans -i /tmp/foo gdb /hurd/hello This is extremely useful if the translator crashes before the startup handshake, but also just plain more convenient th

[PATCH 1/2] Externalize libfshelp's service_fsys_startup

Hello, This patch prepares libfshelp's function service_fsys_startup for use elsewhere. It just moves the function to its own file and prefixes its name with fshelp_. I also took the liberty of moving its one out parameter to the end of the parameter list, and pruning out headers which are no lo

[PATCH 0/2] Implement settrans --interactive patch series

Hello, I'm going to post 2 patches that implements a new useful feature to settrans. The first one exposes needed functionallity in libfshelp and the second one implements the feature. More info in the patch mails themselves. (This is the first time I'm trying `tg mail' so please bear with me i

[bug #29463] Translators output garbage when started with settrans -P and stopped by gdb

URL: Summary: Translators output garbage when started with settrans -P and stopped by gdb Project: The GNU Hurd Submitted by: hammy Submitted on: Wed 07 Apr 2010 08:54:08 PM CEST Cate

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #9, bug #28934 (project hurd): I don't see how the regression is possible given that the changes to the exec server should only affect shell scripts not C programs. Also your patch to glibc doesn't actually make use of _hurd_exec_file_name, which makes the above even more bizarr

Re: Hurd vs. Google Summer of Code 2010

Hi, On Thu, Mar 11, 2010 at 03:33:56PM +0100, olafbuddenha...@gmx.net wrote: > On Thu, Mar 11, 2010 at 01:18:05PM +0100, Carl Fredrik Hammar wrote: > > On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net > > wrote: > > > > > Thanks for both the

Re: Hurd vs. Google Summer of Code 2010

Hi, On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net wrote: > On Wed, Mar 10, 2010 at 02:43:35PM +0100, Thomas Schwinge wrote: > > On Wed, Mar 10, 2010 at 08:02:30AM +0100, olafbuddenha...@gmx.net > > wrote: > > > > The results of my labour are available from > > > > > >http

Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

On Sat, Feb 27, 2010 at 09:40:55PM +0600, Ivan Shmakov wrote: > > Giving them new names, e.g. _hurd_exec_path, might be a good idea to > > avoid incompatibilities, > > FWIW, this seems to be the most reasonable solution to me. > > But note that there's a slight terminology issue here: > > --c

Re: [bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

ll the time anyways. > >>>>> Carl Fredrik Hammar writes: > > [...] > > > The reason argv[0] is expanded is because it is passed as an argument > > to the interpreter, otherwise the interpreter can't find it. > > > Because the exec server

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #6, bug #28934 (project hurd): > > The reason argv[0] is expanded is because it is passed as an argument > > to the interpreter, otherwise the interpreter can't find it. > > Unless it is a relative path, of course. I did mean any path, relative or not. What's important is tha

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #4, bug #28934 (project hurd): I researched further how argv[0] is supposed to be handled and have a much firmer grasp on the situation now. argv[0] is only expanded to path to the executed file when the executed file is a #!-script. This means that touching argv[0] in execve(

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

Follow-up Comment #2, bug #28934 (project hurd): Hi Emilio, I'm pretty sure you are correct in that execve() should not look in $PATH, because glibc's sysdeps/mach/hurd/execve.c does a regular file lookup. As you say the exec server gets confused since it does not find bar in $PATH, and tries to

Re: [PATCH] Cast to ioctl_handler_t instead of its definition

Hi, On Mon, Aug 31, 2009 at 09:46:03PM +0200, olafbuddenha...@gmx.net wrote: > On Wed, Aug 26, 2009 at 02:17:21PM +0200, Carl Fredrik Hammar wrote: > > > This is an obvious fix to glibc that makes it easier to change > > `ioctl_handler_t'. > > Note that while we can

Re: [PATCH] Reopen file descriptor on lookup

Hi, On Sun, Aug 30, 2009 at 02:50:05PM +0200, olafbuddenha...@gmx.net wrote: > On Wed, Aug 26, 2009 at 02:19:28PM +0200, Carl Fredrik Hammar wrote: > > > diff --git a/hurd/lookup-retry.c b/hurd/lookup-retry.c > > index 96968f8..ce9eaf0 100644 > > --- a/hurd/lookup-retry

Re: Generalizing mobility for the Hurd

Hi On Wed, Feb 10, 2010 at 12:34:21PM +0100, Thomas Schwinge wrote: > > As for the thesis itself: I read it (while waiting for the train home > from FOSDEM -- I had some hours to spend there), and I liked it! :-) And I'm glad you liked it! :-) > And, as far as I know, it's the first real docum

Re: update-grub2

On Tue, Feb 09, 2010 at 05:36:31PM +0100, Samuel Thibault wrote: > Jakub Daniel, le Tue 09 Feb 2010 17:21:39 +0100, a écrit : > > It didnt work for me :(, it still complains about not having the list of > > partitions... > > IIRC there's such warning but it's just a warning, the command still > co

Re: update-grub2

Hi, On Tue, Feb 09, 2010 at 11:41:25AM +0100, Jakub Daniel wrote: > It's been some time since I last attempted to run Hurd.. Now I installed > hurd under kvm and found out that the networking actually worked in it.. so > I happily installed grub2 from repositories but unfortunately unlike last > t

Re: [bug #28446] No checks are made for unteminated strings in RPC messages

Hi, On Sat, Jan 09, 2010 at 07:10:30PM +0100, olafbuddenha...@gmx.net wrote: > On Thu, Jan 07, 2010 at 04:45:57PM +0100, Carl Fredrik Hammar wrote: > > On Mon, Jan 04, 2010 at 03:34:07PM +0100, olafbuddenha...@gmx.net > > wrote: > > > On a technical side, you have to de

[bug #28779] libstore/ext2fs issue with sparse store

Follow-up Comment #3, bug #28779 (project hurd): I have attached a patch that makes diskfs_S_file_get_storage_info in ext2fs return EOPNOTSUPP if the file is sparse. It also removes any code used for hole mapping, which is now dead. It works for me (TM). (file #19634)

Re: Generalizing mobility for the Hurd

On Sat, Feb 06, 2010 at 04:59:56PM +0100, Michael Banck wrote: > On Fri, Jan 29, 2010 at 02:53:04PM +0100, Carl Fredrik Hammar wrote: > > For now it is available from my personal web page provided by my uni: > > <http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pd

[bug #28779] libstore/ext2fs issue with sparse store

Follow-up Comment #2, bug #28779 (project hurd): > So it is clear that ext2fs (or possibly libstore) > has messed up encoding the blocks of the file, but I > can't really tell what's wrong ATM. Possibly this > could be a general bug in how ext2fs manages holes > in files, so it should be further

  1   2   3   >