Svante Signell, le Tue 22 Jan 2013 20:53:06 +0100, a écrit :
> Updated patch attached (not reindented). Shall I continue sending
> patches or not?
Well, this one doesn't actually do much, so we need to see the others to
be able to say anything.
> And what about submitting to debian-hurd instead o
The fmh function could in some cases mistakenly call vm_map with a null
size. A recent kernel fix made that invalid and return KERN_INVALID_ARGUMENT,
which isn't an expected code here, resulting in the linker not starting.
Avoid calling vm_map when the computed mapping size is null to fix the
probl
On Tue, 2013-01-22 at 20:37 +0100, Svante Signell wrote:
> On Tue, 2013-01-22 at 19:01 +0100, Samuel Thibault wrote:
> > Svante Signell, le Tue 22 Jan 2013 18:53:43 +0100, a écrit :
> > > Attached is the first patch for a 3-way split of hurdselect.c into three
> > > cases: DELAY, POLL, SELECT leadi
Alle martedì 22 gennaio 2013, Svante Signell ha scritto:
> On Tue, 2013-01-22 at 19:15 +0100, Pino Toscano wrote:
> > Alle martedì 22 gennaio 2013, Svante Signell ha scritto:
> > > Attached is the first patch for a 3-way split of hurdselect.c
> > > into three cases: DELAY, POLL, SELECT
> >
> > Wha
On Tue, Jan 22, 2013 at 08:40:11PM +0100, Svante Signell wrote:
> > theorically, poll could be fixed also without restructing hurdselect...
>
> We have discussed this issue before. Let's see what others say.
Minimizing the amount of code change looks better to me. We could however
isolate the res
On Tue, 2013-01-22 at 19:01 +0100, Samuel Thibault wrote:
> Svante Signell, le Tue 22 Jan 2013 18:53:43 +0100, a écrit :
> > Attached is the first patch for a 3-way split of hurdselect.c into three
> > cases: DELAY, POLL, SELECT leading to a more POSIX conforming POLL.
>
> It is way more readable
On Tue, 2013-01-22 at 19:15 +0100, Pino Toscano wrote:
> Hi,
>
> Alle martedì 22 gennaio 2013, Svante Signell ha scritto:
> > Attached is the first patch for a 3-way split of hurdselect.c into
> > three cases: DELAY, POLL, SELECT
>
> What's the use of of the separate DELAY case?
> Basically, it s
Pino Toscano, le Tue 22 Jan 2013 19:15:38 +0100, a écrit :
> > Starting point is the hurdselect.c created by all Debian patches
> > applied up to eglibc-2.13-38 + 3 additional patches:
>
> Note that if you want to send patches upstream, your code must apply
> on master branch of glibc.git, not on
On Tue, 2013-01-22 at 19:15 +0100, Pino Toscano wrote:
> Hi,
>
> Alle martedì 22 gennaio 2013, Svante Signell ha scritto:
...
> > const int fd = (int) d[i].io_port;
> >
> > - if (fd < _hurd_dtablesize)
> > - {
> > d[i].cell = _hurd_dtable[fd];
>
Hi,
Alle martedì 22 gennaio 2013, Svante Signell ha scritto:
> Attached is the first patch for a 3-way split of hurdselect.c into
> three cases: DELAY, POLL, SELECT
What's the use of of the separate DELAY case?
Basically, it seems to be optimizing just a very specific case, i.e.:
select(0, ...,
Svante Signell, le Tue 22 Jan 2013 18:53:43 +0100, a écrit :
> Attached is the first patch for a 3-way split of hurdselect.c into three
> cases: DELAY, POLL, SELECT leading to a more POSIX conforming POLL.
It is way more readable that the previous versions :)
> + if (nfds > _hurd_dtablesize)
> +
Hi,
Attached is the first patch for a 3-way split of hurdselect.c into three
cases: DELAY, POLL, SELECT leading to a more POSIX conforming POLL. The
Hurd servers pflocal and pfinet are already prepared for this update.
Starting point is the hurdselect.c created by all Debian patches applied
up to
12 matches
Mail list logo
