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 gathe
> 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.
> Ho
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 c
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:
> John Anthony Kazos Jr. <[EMAIL PROTECTED]> wrote:
>
>> if (veryverylengthycondition1
>> && smallcond2
>> && (conditionnumber3a
>> || condition3b)) {
>> ...
>> }
>>
>> Clear, crisp, an
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, s
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 linux-ker
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 consens
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 (veryverylengthyc
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
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.
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 &&
> smallcond
> 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 A
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
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
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 i
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&m=117309251916053&w=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 u
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 sin
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 single-stepping
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
> > +++ linux-2.6/include/asm-i386/th
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 *curr
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
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 such
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 we
36 matches
Mail list logo
