[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANsc=4X+8He-w9wr0xbtDkJhxw8H13kk_-OV07jMZ7govTnmxQ@mail.gmail.com>
Date: Fri, 24 Jan 2014 14:34:41 -0500
From: Adrien Vergé <adrienverge@...il.com>
To: Christopher Covington <cov@...eaurora.org>
Cc: Will Deacon <will.deacon@....com>,
Russell King <linux@....linux.org.uk>,
Catalin Marinas <Catalin.Marinas@....com>,
Ben Dooks <ben.dooks@...ethink.co.uk>,
"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Randy Dunlap <rdunlap@...radead.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Dirk Behme <dirk.behme@...bosch.com>,
Michel Dagenais <michel.dagenais@...ymtl.ca>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 4/6] ARM: Make PID_IN_CONTEXTIDR incompatible with PID_NS
2014/1/24 Will Deacon <will.deacon@....com>:
> I think I'd rather have the global ID than disable a potentially useful
> feature, especially since this is likely to be consumed by external trace
> tools as opposed to user-space tasks.
I understand.
2014/1/24 Christopher Covington <cov@...eaurora.org>:
> Would it be reasonable to make what's
> written to the CONTEXTIDR run-time configurable? If so, what would be the best
> interface for configuring it?
This is an interesting option.
An other option would be to keep the global PID in the Context ID
register, and rely on kernel support to translate virtual PID to
global PID when needed. Then, it would be possible to select a task to
trace via its PID, by asking the kernel to write its global ID to the
Context ID comparator.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists