Christian Gennerat wrote:
About Standard aliases:
modprobe -c
...
alias ppp-compress-21 bsd_comp
...
Why bsd_comp is the standard alias?
/src/linux/Configure.help says that
The PPP Deflate compression method ("PPP Deflate compression",
above) is preferable to BSD-Compress,
you ignore the existing POSIX timer API?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API is a standard and a very good one. Too bad it does
not deliver to files. The timerfd code is, as you can probably
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
So extend the existing POSIX timer API to deliver expiry events via a
fd
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Try reading the timer_create man page.
In short, you're limited to a single clock, so you can't set timers
based on wall-clock time (subject to NTP correction), monotomic time
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
That's what the sigevent structure is for -- to describe how events
should be signaled to userspace, whether by signal delivery, thread
creation, or queuing to event completion ports
On Sat, 2007-03-10 at 14:42 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Care to elaborate on why they're a horrible crock?
It's a *classic* case of an interface that tries to do everything under
the sun.
Here's a clue: look at any system call that takes
On Sat, 2007-03-10 at 16:35 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
I'd actually much rather do POSIX timers the other way around: associate
a
generic notification mechanism with the file descriptor, and then
implement posix_timer_create
On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
If that's the goal, somebody should start thinking about reducing the
contents of struct file to the bare minimum (i.e. not much more than a
file_operations pointer).
That's already
On Sat, 2007-03-10 at 21:31 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Ah, I see. You're just interested in fds as a generic handle concept,
and not a more Plan 9 type thing.
Indeed. It's a handle.
UNIX has pid's for process handles, and file
of
relative (and no TFD_TIMER_REL or TFD_TIMER_SEQ at all).
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On Sun, 2007-03-11 at 16:50 -0700, Nicholas Miell wrote:
You should probably make it behave like the other things that use
itimerspec, just to avoid confusion -- i.e. timers are relative by
default, there's a flag that makes them absolute, they expire when
it_value specifies, and repeat every
the garbage high bits. Of course, nobody else does this, so you still
have to use (void*)NULL to be portable.)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
running with a high enough priority?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
On Sat, 2007-03-17 at 06:56 +0100, Mike Galbraith wrote:
On Fri, 2007-03-16 at 21:24 -0700, Nicholas Miell wrote:
Sorry, I haven't really been following this thread and now I'm confused.
You're saying that it's somehow the scheduler's fault that X isn't
running with a high enough
server-side anyway, so stray
ancient libraries won't be a problem.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
(sorry for the duplicate Ingo, this time I managed to Repy to All)
On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
* Nicholas Miell [EMAIL PROTECTED] wrote:
The X people have plans for how to go about fixing this, [...]
then we'll first have wait for those X changes to at least
involved in pthread creation and destruction.
I don't see any way around the pthread issues other than making a libc
upcall on return from the first system call that blocked.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote:
On Fri, 2 Mar 2007, Nicholas Miell wrote:
The point Ingo was making is that the x86 ABI already requires the FPU
context to be saved before *all* function calls.
I've not seen that among Ingo's points, but yeah some status
/FIFO/RR/etc. -- is it's own separate component).
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
fn2(int x, int y);
int x, y;
};
void testCall(struct test *t, int x, int y)
{
t-fn1(x, y);
t-fn2(x, y);
}
generate instruction-for-instruction identical code.
--
Nicholas Miell [EMAIL
?
--
Nicholas Miell [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
if status was returned for a child
process that terminated due to the receipt of a signal that was
not caught (see signal.h).
So there's no dilemma at all and Linux is non-conformant.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
field
and be delivered via a signalfd.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
, for that matter).
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
operand.
-Andi
GCC counts newlines and semicolons and uses that number as the likely
instruction count.
See asm_insn_count() in gcc/gcc/final.c
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
, convince
everybody to switch from ext3 to this new filesystem, and then maybe
inotify could start doing recursive subtree watches. Otherwise, it's
just not feasible.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
/scaling/linux-mysql.png
(There's also some interesting FreeBSD vs. Linux graphs in
http://people.freebsd.org/~kris/scaling/Scalability%20Update.pdf , but
AFAIK those comparisons are more indicative of glibc malloc performance
than Linux performance.)
--
Nicholas Miell [EMAIL PROTECTED
On Wed, 2007-10-10 at 12:14 +0200, Ingo Molnar wrote:
* Nicholas Miell [EMAIL PROTECTED] wrote:
Does CFS still generate the following sysbench graphs with 2.6.23, or
did that get fixed?
http://people.freebsd.org/~kris/scaling/linux-pgsql.png
http://people.freebsd.org/~kris/scaling
that's true in practice is another matter entirely, of course.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
steal from Solaris instead of anything
ptrace-based?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
:10.0
-0700
@@ -284,7 +284,7 @@
}
int page_fault_trace = 0;
-int exception_trace = 1;
+int exception_trace = 0;
/*
* This routine handles page faults. It determines the address,
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
that,
this problem would be much, much smaller.
-hpa
Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to do
this?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
On Wed, 2005-08-03 at 11:03 +0200, Andi Kleen wrote:
On Wed, Jul 27, 2005 at 11:53:30PM -0700, Nicholas Miell wrote:
debug.exception-trace causes a large amount of log spew when on, and
it's on by default, which is an irritation.
Here's a patch to turn it off.
Rejected.
Why?
Getting
.
Failing to do this makes certain well-know apps (*cough* Sun Java
*cough*) fail to run, which seems to be rather unhelpful.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Sun, 2005-08-07 at 12:49 +0100, Alan Cox wrote:
On Sad, 2005-08-06 at 20:52 -0700, Nicholas Miell wrote:
Why does overcommit in mode 2 (OVERCOMMIT_NEVER) explicitly force
MAP_NORESERVE mappings to reserve memory?
My understanding is that MAP_NORESERVE is a way for apps to state
probably
use the official all-lowercase C99 version.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
.)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the inlined functions involved, this looks an awful lot
like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Perhaps SUSE should fix their gcc instead of working around compiler
problems in the kernel?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux
is getting lost.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
only.
Pekka
You could try passing the --callgraph option to opcontrol.
--
Nicholas Miell [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
equivalent to
accessing the same robust futex from different machines via a shared
filesystem and there's no reason to expect either operation to work
correctly.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
he's asking for a way to copy an existing mapping, which does
sound genuinely useful. (i.e. mremap(ptr, size, size, MREMAP_COPY), with
no need to mess with files to get multiple mappings of the same region)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
there!
signalfd still has the broken behavior w.r.t. signal delivery to
threads.
Is this going to get fixed before 2.6.22 proper is released, or should
it just be disabled entirely so no userspace apps grow to depend on
current wrong behavior?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from
On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
On Sun, 17 Jun 2007, Nicholas Miell wrote:
On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote:
In a stunning turn of events, I've actually been able to make another -rc
release despite all the discussion (*cough*flaming
On Sun, 2007-06-17 at 16:49 -0700, Davide Libenzi wrote:
On Sun, 17 Jun 2007, Nicholas Miell wrote:
On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
On Sun, 17 Jun 2007, Nicholas Miell wrote:
On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote:
In a stunning turn
for
the current thread.
You'd lose the ability to pass signalfds around to other processes, but
I'm not convinced that is even useful. (But I'm sure somebody smarter
than me has a valid use case and would love to share :-)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
On Fri, 22 Jun 2007, Nicholas Miell wrote:
You could just get rid of the process/sighand/whatever reference
entirely and just make reads on a signalfd always dequeue signals for
the current thread.
Duh?! ...
You'd lose
delivery enough to know if it is possible without
unpleasant contortions to make it work.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
0100
#endif
+#ifndef O_CLOEXEC
+#define O_CLOEXEC0200/* set close_on_exec */
+#endif
#ifndef O_NDELAY
#define O_NDELAY O_NONBLOCK
#endif
O_CLOSEONEXEC, perhaps?
We don't want to create another creat here... :)
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe
.
Is there a reason why signalfd() doesn't behave like regular signals in
this regard?
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
signalfd() doesn't deliver thread-targeted signals to the wrong
threads,
does it?
Hmm.
It looks like reading from a signalfd will give you either
process
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more concerned about the design of the API.
Naively, I would expect a reads on a signalfd to return either process
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more
the signal can't be
delivered
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
swapped out. You need to zero all
once-mlocked pages before they get reused to prevent that page from
getting swapped to disk or application bugs from leaking the key.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
need fopenat/funlinkat, etc. Any reasons?
Ulrich having an odd taste?
Solaris compatibility.
--
Nicholas Miell [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Christian Gennerat wrote:
>
> About Standard aliases:
> > modprobe -c
> ...
> alias ppp-compress-21 bsd_comp
> ...
>
> Why bsd_comp is the standard alias?
> /src/linux/Configure.help says that
>
> The PPP Deflate compression method ("PPP Deflate compression",
> above) is preferable to
bugging interfaces from other
operating systems, could we steal from Solaris instead of anything
ptrace-based?
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
On Wed, 2005-08-03 at 11:03 +0200, Andi Kleen wrote:
> On Wed, Jul 27, 2005 at 11:53:30PM -0700, Nicholas Miell wrote:
> > debug.exception-trace causes a large amount of log spew when on, and
> > it's on by default, which is an irritation.
>
> > Here's a patch to turn i
.
Failing to do this makes certain well-know apps (*cough* Sun Java
*cough*) fail to run, which seems to be rather unhelpful.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
On Sun, 2005-08-07 at 12:49 +0100, Alan Cox wrote:
> On Sad, 2005-08-06 at 20:52 -0700, Nicholas Miell wrote:
> > Why does overcommit in mode 2 (OVERCOMMIT_NEVER) explicitly force
> > MAP_NORESERVE mappings to reserve memory?
> >
> > My understanding is that MAP_
:10.0
-0700
@@ -284,7 +284,7 @@
}
int page_fault_trace = 0;
-int exception_trace = 1;
+int exception_trace = 0;
/*
* This routine handles page faults. It determines the address,
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe l
inux
> kernels that the dcache/icache is precious, and that it's way too eager
> to dump dcache and icache in favour of data blocks. If I could do that,
> this problem would be much, much smaller.
>
> -hpa
Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to
rt_cmp_val = hpet_readl(HPET_T0_CMP);
> do {
When you examine the inlined functions involved, this looks an awful lot
like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Perhaps SUSE should fix their gcc instead of working around compiler
problems in the kernel?
--
Nicholas Miell
hould be doing this no matter what), and inlining
hpet_readl into wait_hpet_tick (otherwise, it can't possibly make any
assumptions about the return values of hpet_readl -- this looks to be a
SUSE-specific over-aggressive optimization), and somewhere along the way
the volatile qualifier is getting
On Sat, 2007-03-10 at 21:31 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Ah, I see. You're just interested in fds as a generic handle concept,
> > and not a more Plan 9 type thing.
>
> Indeed. It's a "handle".
&
spec, just to avoid confusion -- i.e. timers are relative by
default, there's a flag that makes them absolute, they expire when
it_value specifies, and repeat every it_interval nanoseconds if
it_interval is non-zero.
i.e.
int timerfd(int ufd, int clockid, int flags, const struct timespec
*utmr);
On Sun, 2007-03-11 at 16:50 -0700, Nicholas Miell wrote:
> You should probably make it behave like the other things that use
> itimerspec, just to avoid confusion -- i.e. timers are relative by
> default, there's a flag that makes them absolute, they expire when
> it_value specifies
platforms.
(This just works in C because C makes NULL ((void*)0) is thus is the
right size. In C++, the 0 ends up being an int instead of a pointer when
passed to a varargs function, and things tend to blow up when they read
the garbage high bits. Of course, nobody else does this, so you still
have t
ion.
>
> If this is your final answer to the problem space, I am done testing,
> and as far as _I_ am concerned, your scheduler is an utter failure.
>
Sorry, I haven't really been following this thread and now I'm confused.
You're saying that it's somehow the scheduler's fault that X isn'
On Sat, 2007-03-17 at 06:56 +0100, Mike Galbraith wrote:
> On Fri, 2007-03-16 at 21:24 -0700, Nicholas Miell wrote:
>
> > Sorry, I haven't really been following this thread and now I'm confused.
> >
> > You're saying that it's somehow the scheduler's fault that X isn't
te.
>
The changes will probably be entirely server-side anyway, so stray
ancient libraries won't be a problem.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
(sorry for the duplicate Ingo, this time I managed to Repy to All)
On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > The X people have plans for how to go about fixing this, [...]
>
> then we'll first have
across function calls, and I'm sure
this is also true of others.
Then there's the other nasty details of new thread creation --
thankfully, the contents of the TLS isn't inherited from the parent
thread, but it still needs to be initialized; not to mention all the
other details involved in pthread crea
On Fri, 2007-03-02 at 16:52 -0800, Davide Libenzi wrote:
> On Fri, 2 Mar 2007, Nicholas Miell wrote:
>
> > The point Ingo was making is that the x86 ABI already requires the FPU
> > context to be saved before *all* function calls.
>
> I've not seen that among Ingo's poin
> with lots of CPUs (eg: solaris). So there is a real challenge here to try to
> provide something at least as good and universal because we know that it can
> exist. And this is what you finally did : work on a scheduler which ought to
> be
> good with any workload.
Solaris ha
call
> to read(2). The read(2) call supportes the O_NONBLOCK flag too, and EAGAIN
> will be returned if no ticks happened.
> A quick test program, shows timerfd working correctly on my amd64 box:
>
> http://www.xmailserver.org/timerfd-test.c
>
Why did you ignore the ex
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > Why did you ignore the existing POSIX timer API?
>
> The existing POSIX API is a standard and a very good one. Too bad it does
> not deliver to files. The timerf
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > >
> > > > Why d
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > > >
> > > > So extend the existing
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > Try reading the timer_create man page.
> >
> > In short, you're limited to a single clock, so you can't set timers
> > based on wall-clock time (subject to N
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > That's what the sigevent structure is for -- to describe how events
> > should be signaled to userspace, whether by signal delivery, thread
> > creation,
On Sat, 2007-03-10 at 14:42 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Care to elaborate on why they're a horrible crock?
>
> It's a *classic* case of an interface that tries to do everything under
> the sun.
>
> Here'
On Sat, 2007-03-10 at 16:35 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> > >
> > > I'd actually much rather do POSIX timers the other way around: associate
> > > a
> > > generic notification mechanism with the
On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > If that's the goal, somebody should start thinking about reducing the
> > contents of struct file to the bare minimum (i.e. not much more than a
> > file_operatio
macros, you should probably
use the official all-lowercase C99 version.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/maj
gh. (And I
suspect this bug has probably been copied to other architectures as
well.)
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
se
> out there!
>
signalfd still has the broken behavior w.r.t. signal delivery to
threads.
Is this going to get fixed before 2.6.22 proper is released, or should
it just be disabled entirely so no userspace apps grow to depend on
current wrong behavior?
--
Nicholas Miell <[EMAIL PROTECTED]>
On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
> On Sun, 17 Jun 2007, Nicholas Miell wrote:
>
> > On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote:
> > > In a stunning turn of events, I've actually been able to make another -rc
> > > release desp
On Sun, 2007-06-17 at 16:49 -0700, Davide Libenzi wrote:
> On Sun, 17 Jun 2007, Nicholas Miell wrote:
>
> > On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote:
> > > On Sun, 17 Jun 2007, Nicholas Miell wrote:
> > >
> > > > On Sat, 2007-
actually calls read()).
Which is weird, to say the least. Definitely needs to be noted in the
man page, which doesn't seem to exist yet.
Is there a reason why signalfd() doesn't behave like regular signals in
this regard?
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
> > signalfd() doesn't deliver thread-targeted signals to the wrong
> > threads,
> > does it?
> >
> > Hmm.
> >
> > It loo
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > Yes, that's certainly wrong, but that's an implementation issue. I was
> > more concerned about the design of the API.
> >
> > Naively, I would expect a reads
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> > > On Tue, 5 Jun 2007, Nicholas Miell wrote:
> > >
> > > > Yes, that's certainly wr
l waiting for signal delivery and the error
is caused by the signal delivery mechanism itself (i.e. a bad pointer
passed to read/select/poll/epoll_wait/etc.) and thus the signal can't be
delivered
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "
mprotect and munmap.
I think he's asking for a way to copy an existing mapping, which does
sound genuinely useful. (i.e. mremap(ptr, size, size, MREMAP_COPY), with
no need to mess with files to get multiple mappings of the same region)
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To un
t; #define O_NOATIME0100
> #endif
> +#ifndef O_CLOEXEC
> +#define O_CLOEXEC0200/* set close_on_exec */
> +#endif
> #ifndef O_NDELAY
> #define O_NDELAY O_NONBLOCK
> #endif
O_CLOSEONEXEC, perhaps?
We don't want to create another "creat&qu
- Ted
The AMD64 psABI requires binaries to work with any page size up to 64k.
Whether that's true in practice is another matter entirely, of course.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
1 - 100 of 116 matches
Mail list logo
