Hi Russell. Your last comments in this thread gave the impression you
thought that ARM's existing PTRACE_SINGLESTEP support would be lost by
converting to the utrace-based ptrace implementation. Christoph Hellwig
posted a reply giving the (correct) details of how this is not the case.
But I
Hi Russell. Your last comments in this thread gave the impression you
thought that ARM's existing PTRACE_SINGLESTEP support would be lost by
converting to the utrace-based ptrace implementation. Christoph Hellwig
posted a reply giving the (correct) details of how this is not the case.
But I
> No need to renumber. You remove TIF_SYSCALL_EMU which is six,
> so the newly added TIF_FORCED_TF could reuse that bit.
No, that would be incorrect. As I mentioned earlier, there are magic
semantics to bits < 16, namely that they are in _TIF_ALLWORK_MASK (and
assembly code knows implicitly
No need to renumber. You remove TIF_SYSCALL_EMU which is six,
so the newly added TIF_FORCED_TF could reuse that bit.
No, that would be incorrect. As I mentioned earlier, there are magic
semantics to bits 16, namely that they are in _TIF_ALLWORK_MASK (and
assembly code knows implicitly that
Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > But the condition doesn't line up with the code:
>
> Exactly. The condition not lining up with the following code helps
> code helps separate the two.
Sorry about that: I realised you were agreeing with me about 5s after I sent
the message.
>
David Howells <[EMAIL PROTECTED]> writes:
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> Not lining up with the code following the if statement is also
>> a plus. Because it clearly delineates the conditions from the code.
>
> But the condition doesn't line up with the code:
Exactly. The
Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Not lining up with the code following the if statement is also
> a plus. Because it clearly delineates the conditions from the code.
But the condition doesn't line up with the code:
if (veryverylengthycondition1 &&
smallcond2
Eric W. Biederman [EMAIL PROTECTED] wrote:
Not lining up with the code following the if statement is also
a plus. Because it clearly delineates the conditions from the code.
But the condition doesn't line up with the code:
if (veryverylengthycondition1
smallcond2
David Howells [EMAIL PROTECTED] writes:
Eric W. Biederman [EMAIL PROTECTED] wrote:
Not lining up with the code following the if statement is also
a plus. Because it clearly delineates the conditions from the code.
But the condition doesn't line up with the code:
Exactly. The condition
Eric W. Biederman [EMAIL PROTECTED] wrote:
But the condition doesn't line up with the code:
Exactly. The condition not lining up with the following code helps
code helps separate the two.
Sorry about that: I realised you were agreeing with me about 5s after I sent
the message.
However
David Howells <[EMAIL PROTECTED]> writes:
> John Anthony Kazos Jr. <[EMAIL PROTECTED]> wrote:
>
>> if (veryverylengthycondition1
>> && smallcond2
>> && (conditionnumber3a
>> || condition3b)) {
>> ...
>> }
>>
>> Clear, crisp,
On 5/1/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
On Tue, 2007-05-01 at 08:05 -0700, Randy Dunlap wrote:
> I prefer this format also, but I'm not sure that we can get it
> into CodingStyle. CodingStyle is about (either) concensus or
> dictum, but I don't see us close to concensus...
Yes,
On 5/1/07, John Anthony Kazos Jr. <[EMAIL PROTECTED]> wrote:
> It's horrid. I'd much rather see
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
> (conditionnumber3a || condition3b)) {
> ...
> }
if (veryverylengthycondition1
From: On Behalf Of Satyam Sharma
> readable and obvious at first glance itself. For example, consider:
^^^
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
> (conditionnumber3a ||
> condition3b)) {
>
John Anthony Kazos Jr. <[EMAIL PROTECTED]> wrote:
> if (veryverylengthycondition1
> && smallcond2
> && (conditionnumber3a
> || condition3b)) {
> ...
> }
>
> Clear, crisp, and 80-wide. I also like how the logical operator
On Tue, 2007-05-01 at 17:07 +0200, Geert Uytterhoeven wrote:
> For clarity, if it fits, I prefer that one, too.
I don't think that was under question, was it?
My point was that I prefer it even when it _doesn't_ fit.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, 01 May 2007 15:16:13 +0100 David Woodhouse wrote:
> On Tue, 2007-05-01 at 11:00 +0200, Geert Uytterhoeven wrote:
> >
> > if (veryverylengthycondition1 &&
> > smallcond2 &&
> > (conditionnumber3a ||
> > condition3b)) {
> > ...
>
On Tue, 2007-05-01 at 08:05 -0700, Randy Dunlap wrote:
> I prefer this format also, but I'm not sure that we can get it
> into CodingStyle. CodingStyle is about (either) concensus or
> dictum, but I don't see us close to concensus...
CodingStyle is mostly about consensus. We don't have a
On Tue, 1 May 2007, David Woodhouse wrote:
> On Tue, 2007-05-01 at 11:00 +0200, Geert Uytterhoeven wrote:
> >
> > if (veryverylengthycondition1 &&
> > smallcond2 &&
> > (conditionnumber3a ||
> > condition3b)) {
> > ...
> > }
>
> > if (veryverylengthycondition1 &&
> > smallcond2 &&
> > (conditionnumber3a ||
> > condition3b)) {
> > ...
> > }
>
> It's horrid. I'd much rather see
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
>
On Tue, 2007-05-01 at 11:00 +0200, Geert Uytterhoeven wrote:
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
> (conditionnumber3a ||
> condition3b)) {
> ...
> }
It's horrid. I'd much rather see
if
On 5/1/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
On Tue, 1 May 2007, Satyam Sharma wrote:
> Actually, the latter style (one condition per line and the && or ||
> operators appearing _before_ the conditions in subsequent lines)
> is quite popular for multi-line compound conditions (well,
On Tue, 1 May 2007, Satyam Sharma wrote:
> Actually, the latter style (one condition per line and the && or ||
> operators appearing _before_ the conditions in subsequent lines)
> is quite popular for multi-line compound conditions (well, I've seen this
> in kernel/workqueue.c,
On Tue, 1 May 2007, Satyam Sharma wrote:
Actually, the latter style (one condition per line and the or ||
operators appearing _before_ the conditions in subsequent lines)
is quite popular for multi-line compound conditions (well, I've seen this
in kernel/workqueue.c, kernel/stop_machine.c,
On 5/1/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
On Tue, 1 May 2007, Satyam Sharma wrote:
Actually, the latter style (one condition per line and the or ||
operators appearing _before_ the conditions in subsequent lines)
is quite popular for multi-line compound conditions (well, I've
On Tue, 2007-05-01 at 11:00 +0200, Geert Uytterhoeven wrote:
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
It's horrid. I'd much rather see
if (veryverylengthycondition1
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
It's horrid. I'd much rather see
if (veryverylengthycondition1
smallcond2
On Tue, 2007-05-01 at 08:05 -0700, Randy Dunlap wrote:
I prefer this format also, but I'm not sure that we can get it
into CodingStyle. CodingStyle is about (either) concensus or
dictum, but I don't see us close to concensus...
CodingStyle is mostly about consensus. We don't have a
On Tue, 1 May 2007, David Woodhouse wrote:
On Tue, 2007-05-01 at 11:00 +0200, Geert Uytterhoeven wrote:
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
It's horrid. I'd
On Tue, 01 May 2007 15:16:13 +0100 David Woodhouse wrote:
On Tue, 2007-05-01 at 11:00 +0200, Geert Uytterhoeven wrote:
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
On Tue, 2007-05-01 at 17:07 +0200, Geert Uytterhoeven wrote:
For clarity, if it fits, I prefer that one, too.
I don't think that was under question, was it?
My point was that I prefer it even when it _doesn't_ fit.
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe
John Anthony Kazos Jr. [EMAIL PROTECTED] wrote:
if (veryverylengthycondition1
smallcond2
(conditionnumber3a
|| condition3b)) {
...
}
Clear, crisp, and 80-wide. I also like how the logical operator on the
From: On Behalf Of Satyam Sharma
readable and obvious at first glance itself. For example, consider:
^^^
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
On 5/1/07, John Anthony Kazos Jr. [EMAIL PROTECTED] wrote:
It's horrid. I'd much rather see
if (veryverylengthycondition1
smallcond2
(conditionnumber3a || condition3b)) {
...
}
if (veryverylengthycondition1
On 5/1/07, David Woodhouse [EMAIL PROTECTED] wrote:
On Tue, 2007-05-01 at 08:05 -0700, Randy Dunlap wrote:
I prefer this format also, but I'm not sure that we can get it
into CodingStyle. CodingStyle is about (either) concensus or
dictum, but I don't see us close to concensus...
Yes, some
David Howells [EMAIL PROTECTED] writes:
John Anthony Kazos Jr. [EMAIL PROTECTED] wrote:
if (veryverylengthycondition1
smallcond2
(conditionnumber3a
|| condition3b)) {
...
}
Clear, crisp, and 80-wide. I also like
Satyam Sharma wrote:
[...]
> The rationale is to make the operator prominent and thus make
> the structure of a complex multi-line compound conditional expression more
> readable and obvious at first glance itself. For example, consider:
>
> if (veryverylengthycondition1 &&
>
> I'm a bit lost here. Are we referring to
>
> if (expr) {
> ...
> } else {
> ...
> }
>
> versus
>
> if (expr) {
> ...
> }
> else {
> ...
> }
This one is already covered by Documentation/CodingStyle
Hi,
On 4/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Mon, 30 Apr 2007 10:11:21 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> I've separated this out under a new subject because some style issues
> that so far aren't documented explicitly are in doubt here, and Roland
> wants and
On Monday 30 April 2007 13:09:17 Andrew Morton wrote:
> On Mon, 30 Apr 2007 10:11:21 +0100 Christoph Hellwig <[EMAIL PROTECTED]>
wrote:
> > I've separated this out under a new subject because some style issues
> > that so far aren't documented explicitly are in doubt here, and Roland
> > wants
On Apr 30 2007 10:09, Andrew Morton wrote:
>
>This is
>
> if (expr1 &&
> expr2)
>
>versus
>
> if (expr1
> && expr2)
>
>the former is more common and is, IMO, more readable.
>
>The latter can be handy sometimes to prevent an 80-col overflow in the
>first
On Mon, 30 Apr 2007 10:11:21 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> I've separated this out under a new subject because some style issues
> that so far aren't documented explicitly are in doubt here, and Roland
> wants and Answer from Andrew.
>
> We also should put clauses on this
On Mon, Apr 30, 2007 at 10:45:10AM +0100, Russell King wrote:
> For the sake of avoiding too much rehash, here's Roland's reply to my
> initial forrey into utrace:
>
> http://marc.info/?l=linux-kernel=117309251916053=2
In that mail Roland suggests keeping the singlestep code entirely
in the
On Mon, Apr 30, 2007 at 10:33:31AM +0100, Russell King wrote:
> > Does the current arm ptrace code support single stepping in kernelspace?
> > If yes we absolutely need to continue to support it.
>
> single stepping of user space code via standard ptrace calls, yes.
>
> > > I'd also like to see
On Mon, Apr 30, 2007 at 10:33:31AM +0100, Russell King wrote:
> On Mon, Apr 30, 2007 at 11:22:00AM +0200, Christoph Hellwig wrote:
> > On Mon, Apr 30, 2007 at 10:18:09AM +0100, Russell King wrote:
> > > Roland's idea of single-stepping is that it *must* be supported by
> > > hardware for utrace to
On Mon, Apr 30, 2007 at 11:22:00AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 30, 2007 at 10:18:09AM +0100, Russell King wrote:
> > Roland's idea of single-stepping is that it *must* be supported by
> > hardware for utrace to use it. There are a number of architectures
> > which can only do
On Mon, Apr 30, 2007 at 10:18:09AM +0100, Russell King wrote:
> Roland's idea of single-stepping is that it *must* be supported by
> hardware for utrace to use it. There are a number of architectures
> which can only do single-stepping by modifying the text of the
> program being single stepped.
On Mon, Apr 30, 2007 at 10:08:40AM +0100, Christoph Hellwig wrote:
> Btw, is there a fundamental reason why an architecture would not support
> single-stepping except for a transition period of porting, i.e. are there
> real hardware limitation in any of our ports?
Roland's idea of
I've separated this out under a new subject because some style issues
that so far aren't documented explicitly are in doubt here, and Roland
wants and Answer from Andrew.
We also should put clauses on this into CodingStyle.
On Sun, Apr 29, 2007 at 09:02:13PM -0700, Roland McGrath wrote:
> >
On Sun, Apr 29, 2007 at 09:02:13PM -0700, Roland McGrath wrote:
> I'm sorry I've taken so long to reply to your review comments.
> I won't dwell on that, and just dive into the discussion.
>
> > --- linux-2.6/include/asm-i386/thread_info.h.utrace-ptrace-compat
> > +++
On Sun, Apr 29, 2007 at 09:02:13PM -0700, Roland McGrath wrote:
I'm sorry I've taken so long to reply to your review comments.
I won't dwell on that, and just dive into the discussion.
--- linux-2.6/include/asm-i386/thread_info.h.utrace-ptrace-compat
+++
I've separated this out under a new subject because some style issues
that so far aren't documented explicitly are in doubt here, and Roland
wants and Answer from Andrew.
We also should put clauses on this into CodingStyle.
On Sun, Apr 29, 2007 at 09:02:13PM -0700, Roland McGrath wrote:
On Mon, Apr 30, 2007 at 10:08:40AM +0100, Christoph Hellwig wrote:
Btw, is there a fundamental reason why an architecture would not support
single-stepping except for a transition period of porting, i.e. are there
real hardware limitation in any of our ports?
Roland's idea of single-stepping
On Mon, Apr 30, 2007 at 10:18:09AM +0100, Russell King wrote:
Roland's idea of single-stepping is that it *must* be supported by
hardware for utrace to use it. There are a number of architectures
which can only do single-stepping by modifying the text of the
program being single stepped. ARM
On Mon, Apr 30, 2007 at 11:22:00AM +0200, Christoph Hellwig wrote:
On Mon, Apr 30, 2007 at 10:18:09AM +0100, Russell King wrote:
Roland's idea of single-stepping is that it *must* be supported by
hardware for utrace to use it. There are a number of architectures
which can only do
On Mon, Apr 30, 2007 at 10:33:31AM +0100, Russell King wrote:
On Mon, Apr 30, 2007 at 11:22:00AM +0200, Christoph Hellwig wrote:
On Mon, Apr 30, 2007 at 10:18:09AM +0100, Russell King wrote:
Roland's idea of single-stepping is that it *must* be supported by
hardware for utrace to use it.
On Mon, Apr 30, 2007 at 10:33:31AM +0100, Russell King wrote:
Does the current arm ptrace code support single stepping in kernelspace?
If yes we absolutely need to continue to support it.
single stepping of user space code via standard ptrace calls, yes.
I'd also like to see utrace
On Mon, Apr 30, 2007 at 10:45:10AM +0100, Russell King wrote:
For the sake of avoiding too much rehash, here's Roland's reply to my
initial forrey into utrace:
http://marc.info/?l=linux-kernelm=117309251916053w=2
In that mail Roland suggests keeping the singlestep code entirely
in the arm
On Mon, 30 Apr 2007 10:11:21 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote:
I've separated this out under a new subject because some style issues
that so far aren't documented explicitly are in doubt here, and Roland
wants and Answer from Andrew.
We also should put clauses on this into
On Apr 30 2007 10:09, Andrew Morton wrote:
This is
if (expr1
expr2)
versus
if (expr1
expr2)
the former is more common and is, IMO, more readable.
The latter can be handy sometimes to prevent an 80-col overflow in the
first line.
But reads like
On Monday 30 April 2007 13:09:17 Andrew Morton wrote:
On Mon, 30 Apr 2007 10:11:21 +0100 Christoph Hellwig [EMAIL PROTECTED]
wrote:
I've separated this out under a new subject because some style issues
that so far aren't documented explicitly are in doubt here, and Roland
wants and Answer
Hi,
On 4/30/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 30 Apr 2007 10:11:21 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote:
I've separated this out under a new subject because some style issues
that so far aren't documented explicitly are in doubt here, and Roland
wants and Answer
I'm a bit lost here. Are we referring to
if (expr) {
...
} else {
...
}
versus
if (expr) {
...
}
else {
...
}
This one is already covered by Documentation/CodingStyle (with the
Satyam Sharma wrote:
[...]
The rationale is to make the operator prominent and thus make
the structure of a complex multi-line compound conditional expression more
readable and obvious at first glance itself. For example, consider:
if (veryverylengthycondition1
smallcond2
I'm sorry I've taken so long to reply to your review comments.
I won't dwell on that, and just dive into the discussion.
> --- linux-2.6/include/asm-i386/thread_info.h.utrace-ptrace-compat
> +++ linux-2.6/include/asm-i386/thread_info.h
> @@ -135,13 +135,13 @@ static inline struct thread_info
I'm sorry I've taken so long to reply to your review comments.
I won't dwell on that, and just dive into the discussion.
--- linux-2.6/include/asm-i386/thread_info.h.utrace-ptrace-compat
+++ linux-2.6/include/asm-i386/thread_info.h
@@ -135,13 +135,13 @@ static inline struct thread_info *curren
On Tue, Dec 05, 2006 at 01:51:45AM -0800, Roland McGrath wrote:
> Thanks very much for your interest in utrace and for your comments.
> Unfortunately, I cannot say exactly when I will be able to respond
> to them in detail. I broke my arm in September and have had a
> difficult recovery,
On Tue, Dec 05, 2006 at 01:51:45AM -0800, Roland McGrath wrote:
Thanks very much for your interest in utrace and for your comments.
Unfortunately, I cannot say exactly when I will be able to respond
to them in detail. I broke my arm in September and have had a
difficult recovery, including a
Thanks very much for your interest in utrace and for your comments.
Unfortunately, I cannot say exactly when I will be able to respond
to them in detail. I broke my arm in September and have had a
difficult recovery, including a second surgery in November, two
weeks ago. I am now immobilized
Thanks very much for your interest in utrace and for your comments.
Unfortunately, I cannot say exactly when I will be able to respond
to them in detail. I broke my arm in September and have had a
difficult recovery, including a second surgery in November, two
weeks ago. I am now immobilized
Hi Roland,
a while ago you posted a set of patches implementing utrace, a very
promising debugging framework. Unfortunately everything around it got
really silent and you haven't been posting updates for a long time.
Thas is rather unfortunate as beeing silent and only posting updates
on your
Hi Roland,
a while ago you posted a set of patches implementing utrace, a very
promising debugging framework. Unfortunately everything around it got
really silent and you haven't been posting updates for a long time.
Thas is rather unfortunate as beeing silent and only posting updates
on your
72 matches
Mail list logo
