Andy Whitcroft writes:
Ok, this is something we need to decide on. Currently we only ask for
consistent spacing on all the mathematic operators. This is mostly as
we do see a large number of non-spaced uses in defines and the like.
I am happy to expand these tests so they are always
Roland McGrath writes:
> It turns out the problem here is that some .o files wind up with their own
> .note.gnu.build-id sections. I got the makefile magic wrong, thinking that
> LDFLAGS_MODULE was a variable specifically for .ko links. It's also used
> in cmd_link_multi-m.
Alan Modra
Roland McGrath writes:
It turns out the problem here is that some .o files wind up with their own
.note.gnu.build-id sections. I got the makefile magic wrong, thinking that
LDFLAGS_MODULE was a variable specifically for .ko links. It's also used
in cmd_link_multi-m.
Alan Modra (binutils
Nigel Cunningham writes:
> I guess I want to persist because all of these issues aren't utterly
> unsolvable. It's just that we don't have the infrastructure yet to
> figure out the solutions to these issues trivially. Take, for example,
Ever heard of the halting problem? :) It's not just a
Nigel Cunningham writes:
I guess I want to persist because all of these issues aren't utterly
unsolvable. It's just that we don't have the infrastructure yet to
figure out the solutions to these issues trivially. Take, for example,
Ever heard of the halting problem? :) It's not just a matter
ower/pmu_battery.ko] undefined!
This fixes the problem by not building pmu_battery.ko on ppc64. There
are no battery-powered ppc64 machines with an Apple PMU, and we can be
reasonably confident there never will be.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff --git a/drivers/p
Ingo Molnar writes:
>
> * Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > static inline void ccids_read_lock(void)
> > {
> > atomic_inc(_lockct);
> > spin_unlock_wait(_lock);
> > }
> >
> > This looks racy, in theory atomic_inc() and spin_unlock_wait() could
Ingo Molnar writes:
* Oleg Nesterov [EMAIL PROTECTED] wrote:
static inline void ccids_read_lock(void)
{
atomic_inc(ccids_lockct);
spin_unlock_wait(ccids_lock);
}
This looks racy, in theory atomic_inc() and spin_unlock_wait() could
be
!
This fixes the problem by not building pmu_battery.ko on ppc64. There
are no battery-powered ppc64 machines with an Apple PMU, and we can be
reasonably confident there never will be.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index
Ingo Molnar writes:
> CFS does measure time elapsed across task-sleep periods (and does
> something similar to what the old scheduler's 'sleep average'
> interactivity mechanism did), but that mechanism measures "time spent
> running during sleep", not "time spent idling".
PowerPC's
Ingo Molnar writes:
CFS does measure time elapsed across task-sleep periods (and does
something similar to what the old scheduler's 'sleep average'
interactivity mechanism did), but that mechanism measures time spent
running during sleep, not time spent idling.
PowerPC's sched_clock()
Andrew Morton writes:
> On Wed, 11 Jul 2007 09:27:40 +1000
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> > We did come up with an order that worked for everybody, but that
> > discussion seemed to get totally ignored by the ext4 developers.
>
> It was a
Segher Boessenkool writes:
> > This scales with the number of processors since there is one
> > decrementer per core (is it per thread on SMT chips?
> > I don't know).
>
> One per core.
No, each thread has its own decrementer, but the timebase is shared.
Paul.
-
To unsubscribe from this list:
Jeff Garzik writes:
> Andrew Morton wrote:
> > So I dropped everything. Let's start again from scratch. I'd suggest that
> > for now we go with just an i386/x86_64 implementation, let the arch
> > maintainers wire things up when that has settled down.
>
>
> It's my observation that that plan
Jens Axboe writes:
> I have no objections to the block bits, however I feel uneasy merging
> the full patchset unless patch #1 has been acked by the platform person.
I have the first 3 patches in my queue, so yes I've acked it. It's
probably easiest if the remaining 3 go through my queue once
Jens Axboe writes:
I have no objections to the block bits, however I feel uneasy merging
the full patchset unless patch #1 has been acked by the platform person.
I have the first 3 patches in my queue, so yes I've acked it. It's
probably easiest if the remaining 3 go through my queue once
Jeff Garzik writes:
Andrew Morton wrote:
So I dropped everything. Let's start again from scratch. I'd suggest that
for now we go with just an i386/x86_64 implementation, let the arch
maintainers wire things up when that has settled down.
It's my observation that that plan usually
Segher Boessenkool writes:
This scales with the number of processors since there is one
decrementer per core (is it per thread on SMT chips?
I don't know).
One per core.
No, each thread has its own decrementer, but the timebase is shared.
Paul.
-
To unsubscribe from this list: send the
Andrew Morton writes:
On Wed, 11 Jul 2007 09:27:40 +1000
Paul Mackerras [EMAIL PROTECTED] wrote:
We did come up with an order that worked for everybody, but that
discussion seemed to get totally ignored by the ext4 developers.
It was a long discussion.
Can someone please remind us
Nigel Cunningham writes:
> (Finally catching up on emails since Saturday!)
Yes, I know what you mean; I was occupied with other work stuff on
Friday and not well on Saturday, and by that stage there was a backlog
of about 500 emails for me to wade through... :/
> The freezer is also essential
Nigel Cunningham writes:
(Finally catching up on emails since Saturday!)
Yes, I know what you mean; I was occupied with other work stuff on
Friday and not well on Saturday, and by that stage there was a backlog
of about 500 emails for me to wade through... :/
The freezer is also essential for
Alan Stern writes:
> In answer to both questions: We need the freezer in order to implement
> hibernate. Even if we take your advice and stop using the freezer
> during suspend, these issues would still remain and would need to be
> solved.
Stepping back for a minute, let's think about what
Alan Stern writes:
In answer to both questions: We need the freezer in order to implement
hibernate. Even if we take your advice and stop using the freezer
during suspend, these issues would still remain and would need to be
solved.
Stepping back for a minute, let's think about what the
Andrea Arcangeli writes:
> So my whole idea is to once and for all to decuple the size of the
> pte-entry (4k on x86/amd64) with the page allocator granularity. The
> HARD_PAGE_SHIFT will be 4k still, the common code PAGE_SIZE will be
> variable and configurable at compile time with
Andrea Arcangeli writes:
So my whole idea is to once and for all to decuple the size of the
pte-entry (4k on x86/amd64) with the page allocator granularity. The
HARD_PAGE_SHIFT will be 4k still, the common code PAGE_SIZE will be
variable and configurable at compile time with
Pavel Machek writes:
> 0. Get someone to sign up as a maintainer for suspend, so we have
> someone to blame for the mess? :-)
I thought that was Rafael?
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Pavel Machek writes:
> How well does it work on SMP PPC?
Just fine, on those machines where we know how to reinitialize the
video card. We currently require userspace to offline all except the
boot cpu before suspending, but that could be moved into the kernel.
I have no particular attachment
Alan Stern writes:
> That's not what I'm saying. What I'm saying is that it would be a big
> mistake to force all drivers which implement runtime PM to do it using
> a separate code path from system PM.
OK; I can accept that provided there is a way to change the "what to
do with an I/O
Alan Stern writes:
> Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> wanting to resume devices during a system suspend transition? This is
> exactly what happens when those threads aren't frozen.
So, I wonder why I don't see that error on my powerbook?
Paul.
-
To
Miklos Szeredi writes:
> OK, let me summarize the situation as I see it now: there are two
> camps, the pro-freezers and the anti-freezers.
>
> Pro-freezers say:
>
> - don't remove the freezer, otherwise we'll have to deal with
> numerous problems in drivers
>
> Anti-freezers say:
>
>
Rafael J. Wysocki writes:
> They will not trigger 100% of the time, but sporadically and generally at
> random.
>
> At least the freezer problems are reproducible. ;-)
Our experience with powermacs has been that it isn't actually all that
hard to get it right for the drivers you care about.
Alan Stern writes:
> > > Yes, the code could be changed to keep track of the reason for a device
> > > suspend. But that just raises the old problem of what to do when
> > > there's an I/O request for a suspended device during STR.
> >
> > Is this actually a real problem? I would think the
Rafael J. Wysocki writes:
> This is incompatible with the code in kernel/power/main.c, since we only
> disable the nonboot CPUs after devices have been suspended. Do you think that
> your framework can be modified to work without disabling the nonboot CPUs
> by the user space?
Sure. It was a
Alan Stern writes:
> Let's agree the kernel threads and the freezer are a separate issue.
No, I don't think they are a separate issue, because I think the
distinction the freezer makes between kernel threads and user threads
is a false and misleading distinction.
> In the most recent kernels,
Rafael J. Wysocki writes:
> They are mostly related to kernel threads, that we've already agreed no to
> freeze (except for the ones that want that, but they will be responsible for
> getting everything right). The initial patches for that are in -mm and more
> will come.
Serious question:
Rafael J. Wysocki writes:
> > > So, I gather, you're volunteering to handle suspend-related bug reports
> > > from the point in which we drop the freezer from the suspend code path?
> >
> > Ben and I are happy to handle all the ones for the platform we
> > maintain, which currently does suspend
Rafael J. Wysocki writes:
> BTW, does your platform's suspend work on SMP systems?
Yes; currently we require userspace to offline all cpus other than the
boot cpu before initiating the suspend.
The main difficulty is actually that SMP powermacs that can suspend
tend to have video cards that get
Oliver Neukum writes:
> They can't. Device specific protocols are known to the drivers only.
> The fact remains, remove the freezer and you need to go through
> all drivers.
The freezer does not actually mean that you don't have to get the
drivers right, because kernel threads can issue I/O
Rafael J. Wysocki writes:
> So, I gather, you're volunteering to handle suspend-related bug reports
> from the point in which we drop the freezer from the suspend code path?
Ben and I are happy to handle all the ones for the platform we
maintain, which currently does suspend without freezing
Rafael J. Wysocki writes:
> Okay, so in fact you don't know.
Don't know what exactly?
It has been a while since I had my head in the USB code. I assume
it's being maintained by competent people. :)
> And that's my point in this thread.
Well, I'd be interested in hearing from Matthew whether
Oliver Neukum writes:
> You cannot simply restart the URB without thinking.
> The device after resumption may or may not be in the stage
> you left it. It needs to be rechecked and some settings must be
> renewed. You cannot simple throw an URB from an arbitrary
> stage of the protocol at it.
>
Oliver Neukum writes:
> > It's not lost, it's sitting in RAM, and will be sent out when you
> > resume.
>
> Unfortunately this is not the case. The URB will error out.
So the higher-level driver needs to do the sensible thing, i.e.,
resubmit the URB after resume. It's not rocket science. The
Oliver Neukum writes:
> > Indeed, and the USB framework has code to know when the host
> > controller is suspended and avoid trying to send out urbs in that
> > case. Or at least it did last time I looked at it in any detail; it's
> > been "just working" - including suspending and resuming,
Miklos Szeredi writes:
> That's weird, I never had a suspend problem due to a fuse mount,
> though I have them all the time. And I suspect, that even the sync()
Well, I don't either, because we don't freeze processes on
powerbooks. But I have heard that other people have problems with
Miklos Szeredi writes:
That's weird, I never had a suspend problem due to a fuse mount,
though I have them all the time. And I suspect, that even the sync()
Well, I don't either, because we don't freeze processes on
powerbooks. But I have heard that other people have problems with
suspending
Oliver Neukum writes:
Indeed, and the USB framework has code to know when the host
controller is suspended and avoid trying to send out urbs in that
case. Or at least it did last time I looked at it in any detail; it's
been just working - including suspending and resuming, without the
Oliver Neukum writes:
It's not lost, it's sitting in RAM, and will be sent out when you
resume.
Unfortunately this is not the case. The URB will error out.
So the higher-level driver needs to do the sensible thing, i.e.,
resubmit the URB after resume. It's not rocket science. The data
Oliver Neukum writes:
You cannot simply restart the URB without thinking.
The device after resumption may or may not be in the stage
you left it. It needs to be rechecked and some settings must be
renewed. You cannot simple throw an URB from an arbitrary
stage of the protocol at it.
Rafael J. Wysocki writes:
So, I gather, you're volunteering to handle suspend-related bug reports
from the point in which we drop the freezer from the suspend code path?
Ben and I are happy to handle all the ones for the platform we
maintain, which currently does suspend without freezing
Rafael J. Wysocki writes:
Okay, so in fact you don't know.
Don't know what exactly?
It has been a while since I had my head in the USB code. I assume
it's being maintained by competent people. :)
And that's my point in this thread.
Well, I'd be interested in hearing from Matthew whether he
Oliver Neukum writes:
They can't. Device specific protocols are known to the drivers only.
The fact remains, remove the freezer and you need to go through
all drivers.
The freezer does not actually mean that you don't have to get the
drivers right, because kernel threads can issue I/O
Rafael J. Wysocki writes:
So, I gather, you're volunteering to handle suspend-related bug reports
from the point in which we drop the freezer from the suspend code path?
Ben and I are happy to handle all the ones for the platform we
maintain, which currently does suspend without
Rafael J. Wysocki writes:
BTW, does your platform's suspend work on SMP systems?
Yes; currently we require userspace to offline all cpus other than the
boot cpu before initiating the suspend.
The main difficulty is actually that SMP powermacs that can suspend
tend to have video cards that get
Rafael J. Wysocki writes:
They are mostly related to kernel threads, that we've already agreed no to
freeze (except for the ones that want that, but they will be responsible for
getting everything right). The initial patches for that are in -mm and more
will come.
Serious question: which
Rafael J. Wysocki writes:
This is incompatible with the code in kernel/power/main.c, since we only
disable the nonboot CPUs after devices have been suspended. Do you think that
your framework can be modified to work without disabling the nonboot CPUs
by the user space?
Sure. It was a if it
Alan Stern writes:
Let's agree the kernel threads and the freezer are a separate issue.
No, I don't think they are a separate issue, because I think the
distinction the freezer makes between kernel threads and user threads
is a false and misleading distinction.
In the most recent kernels,
Miklos Szeredi writes:
OK, let me summarize the situation as I see it now: there are two
camps, the pro-freezers and the anti-freezers.
Pro-freezers say:
- don't remove the freezer, otherwise we'll have to deal with
numerous problems in drivers
Anti-freezers say:
- let's
Rafael J. Wysocki writes:
They will not trigger 100% of the time, but sporadically and generally at
random.
At least the freezer problems are reproducible. ;-)
Our experience with powermacs has been that it isn't actually all that
hard to get it right for the drivers you care about.
Paul.
Alan Stern writes:
Yes, the code could be changed to keep track of the reason for a device
suspend. But that just raises the old problem of what to do when
there's an I/O request for a suspended device during STR.
Is this actually a real problem? I would think the policy would be
Alan Stern writes:
That's not what I'm saying. What I'm saying is that it would be a big
mistake to force all drivers which implement runtime PM to do it using
a separate code path from system PM.
OK; I can accept that provided there is a way to change the what to
do with an I/O request
Alan Stern writes:
Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
wanting to resume devices during a system suspend transition? This is
exactly what happens when those threads aren't frozen.
So, I wonder why I don't see that error on my powerbook?
Paul.
-
To
Pavel Machek writes:
How well does it work on SMP PPC?
Just fine, on those machines where we know how to reinitialize the
video card. We currently require userspace to offline all except the
boot cpu before suspending, but that could be moved into the kernel.
I have no particular attachment to
Pavel Machek writes:
0. Get someone to sign up as a maintainer for suspend, so we have
someone to blame for the mess? :-)
I thought that was Rafael?
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Alan Stern writes:
> USB already implements runtime PM. If a device is suspended at runtime
> and a task tries to access it, the device is automatically resumed.
> No problem there.
>
> The problem comes when the system is doing a STR. Right now the code
> doesn't keep track of the
Alan Stern writes:
> I disagree. The problem isn't the kernel calling userspace; it's
> userspace trying to do I/O at a time when everything is supposed to be
> quiescing. Detecting that and blocking it in drivers is hard and
> error-prone; preventing it by freezing userspace is easy and cheap.
Alan Stern writes:
> > Most drivers suspended their hardware in the second call. If they are
> > in the middle of a conversation with their device that *has* to be
> > completed, they can do that by polling.
>
> Ugh. That will cause problems when you try to integrate runtime
> suspend. In
Rafael J. Wysocki writes:
> Now, please tell me how many driver writers even thought that something
> might try to access their devices after .suspend() had been executed (or
> even whilie it was being executed)?
Well, I believe that the USB framework copes with this, except
possibly for some
Rafael J. Wysocki writes:
> Still, do you really think that we're ready to drop it _right_ _now_ (I'm
> referring to suspend only) and if so than on what basis (except that you
> don't like it, which falls short of being a techical argument)?
The basis is that it (the freezer) causes more
Oliver Neukum writes:
> That's why we have the problem of freezing the kernel threads or not.
That problem is a symptom of the deeper conceptual problem, as is the
problem with FUSE.
> You want to have all that pain for fuse?
I'd certainly rather get the drivers right, and maybe have an
Oliver Neukum writes:
> USB devices certainly have suspend methods.
Indeed, and the USB framework has code to know when the host
controller is suspended and avoid trying to send out urbs in that
case. Or at least it did last time I looked at it in any detail; it's
been "just working" -
Oliver Neukum writes:
> At the risk of repeating myself. Character device drivers are written
> with the assumption that normal io and suspend/resume do not race
> with each other due to the freezer.
> What do you intend to do about that?
Going back to the old powerbook sleep code, we had a
Oliver Neukum writes:
At the risk of repeating myself. Character device drivers are written
with the assumption that normal io and suspend/resume do not race
with each other due to the freezer.
What do you intend to do about that?
Going back to the old powerbook sleep code, we had a
Oliver Neukum writes:
USB devices certainly have suspend methods.
Indeed, and the USB framework has code to know when the host
controller is suspended and avoid trying to send out urbs in that
case. Or at least it did last time I looked at it in any detail; it's
been just working - including
Oliver Neukum writes:
That's why we have the problem of freezing the kernel threads or not.
That problem is a symptom of the deeper conceptual problem, as is the
problem with FUSE.
You want to have all that pain for fuse?
I'd certainly rather get the drivers right, and maybe have an
Alan Stern writes:
Most drivers suspended their hardware in the second call. If they are
in the middle of a conversation with their device that *has* to be
completed, they can do that by polling.
Ugh. That will cause problems when you try to integrate runtime
suspend. In fact this
Rafael J. Wysocki writes:
Now, please tell me how many driver writers even thought that something
might try to access their devices after .suspend() had been executed (or
even whilie it was being executed)?
Well, I believe that the USB framework copes with this, except
possibly for some
Rafael J. Wysocki writes:
Still, do you really think that we're ready to drop it _right_ _now_ (I'm
referring to suspend only) and if so than on what basis (except that you
don't like it, which falls short of being a techical argument)?
The basis is that it (the freezer) causes more deadlocks
Alan Stern writes:
USB already implements runtime PM. If a device is suspended at runtime
and a task tries to access it, the device is automatically resumed.
No problem there.
The problem comes when the system is doing a STR. Right now the code
doesn't keep track of the difference
Alan Stern writes:
I disagree. The problem isn't the kernel calling userspace; it's
userspace trying to do I/O at a time when everything is supposed to be
quiescing. Detecting that and blocking it in drivers is hard and
error-prone; preventing it by freezing userspace is easy and cheap.
Jason Wessel writes:
> I suppose the argument could be made to remove the check in the compiled
> file, but it does serve as a way to protect kgdb for now if someone
> tries to hard compile in xmon and kgdb. Completely unpredictable
> results will occur with the debugger unless some pieces
Jason Wessel writes:
I suppose the argument could be made to remove the check in the compiled
file, but it does serve as a way to protect kgdb for now if someone
tries to hard compile in xmon and kgdb. Completely unpredictable
results will occur with the debugger unless some pieces are
Jeremy Fitzhardinge writes:
> ===
> --- a/arch/powerpc/platforms/cell/io-workarounds.c
> +++ b/arch/powerpc/platforms/cell/io-workarounds.c
> @@ -9,6 +9,7 @@
> #undef DEBUG
>
> #include
> +#include
Why is this needed? You've
Jeremy Fitzhardinge writes:
> powerpc also appears to have its own duplicate copy of elf.h in
> arch/powerpc/boot/elf.h; presumably because the standard elf.h
> brings in too much. Update it to just linux/elf-defn.h, which
> should be fine.
No, it's because the bootwrapper is not part
Jeremy Fitzhardinge writes:
powerpc also appears to have its own duplicate copy of elf.h in
arch/powerpc/boot/elf.h; presumably because the standard elf.h
brings in too much. Update it to just linux/elf-defn.h, which
should be fine.
No, it's because the bootwrapper is not part of
Jeremy Fitzhardinge writes:
===
--- a/arch/powerpc/platforms/cell/io-workarounds.c
+++ b/arch/powerpc/platforms/cell/io-workarounds.c
@@ -9,6 +9,7 @@
#undef DEBUG
#include linux/kernel.h
+#include linux/sched.h
Why is
Dave Hansen writes:
> Several of our on-disk filesystems have an ioctl function that already
> has indented goto labels. I don't think it's quite worth churning all
> of these (working) filesystems to make a style checker happy.
I agree.
> I think it's worse style to be mixing label
Alan Cox writes:
> On Fri, 22 Jun 2007 11:39:45 +0800
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote:
> > > Users should use the libata based drivers for SATA drives.
> >
> > NAK. Not all IDE drivers are converted yet. Not even all the
Alan Cox writes:
On Fri, 22 Jun 2007 11:39:45 +0800
David Woodhouse [EMAIL PROTECTED] wrote:
On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote:
Users should use the libata based drivers for SATA drives.
NAK. Not all IDE drivers are converted yet. Not even all the relatively
Dave Hansen writes:
Several of our on-disk filesystems have an ioctl function that already
has indented goto labels. I don't think it's quite worth churning all
of these (working) filesystems to make a style checker happy.
I agree.
I think it's worse style to be mixing label indentation in
Davide Libenzi writes:
> > Why must everything that makes things a bit simpler and more
> > predictable for application programmers be called a "mistake"?
>
> Because if you give guarantees on something, ppl start using such
> guarantee in the wrong way. Kyle's email summarizes it.
OK, my
Kyle Moffett writes:
> 1) Linear FD allocation makes it IMPOSSIBLE for libraries to
> reliably use persistent FDs behind an application's back. For
That's not completely true; for example, openlog() opens a file
descriptor for the library's own use, as does sethostent(). I agree
that it
Davide Libenzi writes:
Why must everything that makes things a bit simpler and more
predictable for application programmers be called a mistake?
Because if you give guarantees on something, ppl start using such
guarantee in the wrong way. Kyle's email summarizes it.
OK, my
Kyle Moffett writes:
1) Linear FD allocation makes it IMPOSSIBLE for libraries to
reliably use persistent FDs behind an application's back. For
That's not completely true; for example, openlog() opens a file
descriptor for the library's own use, as does sethostent(). I agree
that it
Davide Libenzi writes:
> The only reason we use a floating base, is because Uli preferred to have
> non-exactly predictable fd allocations. There no reason of re-doing the
> same POSIX mistake all over again:
Why must everything that makes things a bit simpler and more
predictable for
Davide Libenzi writes:
The only reason we use a floating base, is because Uli preferred to have
non-exactly predictable fd allocations. There no reason of re-doing the
same POSIX mistake all over again:
Why must everything that makes things a bit simpler and more
predictable for application
Linus Torvalds writes:
> So I think that the *right* place to clear TIF_SIGPENDING is actually in
> "get_signal_to_deliver()", because that function is called _only_ by the
> actual per-architecture "I'm going to deliver a signal now".
I agree that's the right place for real user processes,
Jeff Dike writes:
> On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
> > Yeah, synchronous signals should probably never be delivered to another
> > process, even via signalfd. There's no point delivering a SEGV to
> > somebody else :-)
>
> Sure there is. UML does exactly
Jeff Dike writes:
On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV to
somebody else :-)
Sure there is. UML does exactly that -
Linus Torvalds writes:
So I think that the *right* place to clear TIF_SIGPENDING is actually in
get_signal_to_deliver(), because that function is called _only_ by the
actual per-architecture I'm going to deliver a signal now.
I agree that's the right place for real user processes, but I
Chris Snook writes:
> Clean up whitespace and comments in drivers/serial/icom.c
These changes seem totally unnecessary, as the existing indentation is
according to a commonly-accepted style and is quite reasonable:
> @@ -149,23 +149,23 @@ static void free_port_memory(struct icom
>
501 - 600 of 1180 matches
Mail list logo
