Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 22, 2016 at 03:23:59PM -0700, Andy Lutomirski wrote: > On Sep 21, 2016 12:28 AM, "Mark Rutland" wrote: > > Given all that, can we make the generic thread_info::flags an unsigned > > long, matching what the thread flag helpers implicitly assume? > > Yes. Want

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 22, 2016 at 03:23:59PM -0700, Andy Lutomirski wrote: > On Sep 21, 2016 12:28 AM, "Mark Rutland" wrote: > > Given all that, can we make the generic thread_info::flags an unsigned > > long, matching what the thread flag helpers implicitly assume? > > Yes. Want to send the patch or

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Sep 21, 2016 12:28 AM, "Mark Rutland" wrote: > > Hi Andy, > > On Fri, Sep 16, 2016 at 08:11:14AM -0700, Andy Lutomirski wrote: > > > On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > > Just to check, what do you mean to happen with the flags field?

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Sep 21, 2016 12:28 AM, "Mark Rutland" wrote: > > Hi Andy, > > On Fri, Sep 16, 2016 at 08:11:14AM -0700, Andy Lutomirski wrote: > > > On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > > Just to check, what do you mean to happen with the flags field? Should > > > that always

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

Hi Andy, On Fri, Sep 16, 2016 at 08:11:14AM -0700, Andy Lutomirski wrote: > > On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > Just to check, what do you mean to happen with the flags field? Should > > that always be in the generic thread_info? e.g. > > > > struct thread_info

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

Hi Andy, On Fri, Sep 16, 2016 at 08:11:14AM -0700, Andy Lutomirski wrote: > > On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > Just to check, what do you mean to happen with the flags field? Should > > that always be in the generic thread_info? e.g. > > > > struct thread_info

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

[Adding Yosinori Sato for h8300] On Fri, Sep 16, 2016 at 08:11:14AM -0700, Andy Lutomirski wrote: > > On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > > On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland > > > wrote: > > Just to check, what do you mean to

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

[Adding Yosinori Sato for h8300] On Fri, Sep 16, 2016 at 08:11:14AM -0700, Andy Lutomirski wrote: > > On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > > On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland > > > wrote: > > Just to check, what do you mean to happen with the flags

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

> On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland wrote: > > > Currently, task_struct is defined in , which (indirectly) > > > pulls in a number of low-level arch headers such as > > > through a number of

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

> On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > > On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland wrote: > > > Currently, task_struct is defined in , which (indirectly) > > > pulls in a number of low-level arch headers such as > > > through a number of other headers. Thus,

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland wrote: > > Currently, task_struct is defined in , which (indirectly) > > pulls in a number of low-level arch headers such as > > through a number of other

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 15, 2016 at 11:37:47AM -0700, Andy Lutomirski wrote: > On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland wrote: > > Currently, task_struct is defined in , which (indirectly) > > pulls in a number of low-level arch headers such as > > through a number of other headers. Thus, code and

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland wrote: > Currently, task_struct is defined in , which (indirectly) > pulls in a number of low-level arch headers such as > through a number of other headers. Thus, code and structures in these > headers can't rely on the

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 15, 2016 at 6:49 AM, Mark Rutland wrote: > Currently, task_struct is defined in , which (indirectly) > pulls in a number of low-level arch headers such as > through a number of other headers. Thus, code and structures in these > headers can't rely on the definition of task_struct.

[RFC PATCH 2/8] thread_info: allow custom in-task thread_info

Currently, task_struct is defined in , which (indirectly) pulls in a number of low-level arch headers such as through a number of other headers. Thus, code and structures in these headers can't rely on the definition of task_struct. Some of these headers are necessary for the definition of

[RFC PATCH 2/8] thread_info: allow custom in-task thread_info

Currently, task_struct is defined in , which (indirectly) pulls in a number of low-level arch headers such as through a number of other headers. Thus, code and structures in these headers can't rely on the definition of task_struct. Some of these headers are necessary for the definition of