[patch 1/5] x86, ptrace: remove bad comment

[patch 1/5] x86, ptrace: remove bad comment

[Markus Metzger]

Remove no longer correct comment.

Signed-off-by: Markus Metzger <markus.t.metzger@intel.com>
---

Index: linux-2.6-x86/arch/x86/kernel/process_64.c
===================================================================
--- linux-2.6-x86.orig/arch/x86/kernel/process_64.c	2007-12-14 15:31:37.%N +0100
+++ linux-2.6-x86/arch/x86/kernel/process_64.c	2007-12-14 15:31:42.%N +0100
@@ -597,10 +597,6 @@
 		memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
 	}
 
-	/*
-	 * Last branch recording recofiguration of trace hardware and
-	 * disentangling of trace data per task.
-	 */
 	if (test_tsk_thread_flag(prev_p, TIF_BTS_TRACE_TS))
 		ptrace_bts_take_timestamp(prev_p, BTS_TASK_DEPARTS);
 
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [patch 1/5] x86, ptrace: remove bad comment

[Ingo Molnar]

Markus,

i've applied the first 4 patches to x86.git.

another detail: shouldnt this be structured so that the APIs are 
introduced in kernel/ptrace.c, and that the architecture offers the 
mechanism. (which would thus be ptrace-independent) This would also open 
these APIs up to kernel-internal use and to be used by other 
architectures.

	Ingo

RE: [patch 1/5] x86, ptrace: remove bad comment

[Metzger, Markus T]

>-----Original Message-----
>From: Ingo Molnar [mailto:mingo@elte.hu] 
>Sent: Samstag, 15. Dezember 2007 08:30

>another detail: shouldnt this be structured so that the APIs are 
>introduced in kernel/ptrace.c, and that the architecture offers the 
>mechanism. (which would thus be ptrace-independent) This would 
>also open 
>these APIs up to kernel-internal use and to be used by other 
>architectures.

Isn't this best done once we actually have at least one other
architecture?

The DS interface should be fine for kernel and user trace on x86, but it
may not be the best interface for other architectures.

regards,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.