va
Subject: Re: [PATCH v5 5/7] ocxl: Expose the thread_id needed for wait on
POWER9
Le 11/05/2018 à 08:13, Alastair D'Silva a écrit :
From: Alastair D'Silva
In order to successfully issue as_notify, an AFU needs to know the TID
to notify, which in turn means that this information should
> Subject: Re: [PATCH v5 5/7] ocxl: Expose the thread_id needed for wait on
> POWER9
>
>
>
> Le 11/05/2018 à 08:13, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > In order to successfully issue as_notify, an AFU needs to know the TID
&
+extern int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
+
/*
* Remove a Process Element from the Shared Process Area for a link
*/
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..561e6f0dfcb7 100644
--- a/include/uapi/misc/oc
a Process Element from the Shared Process Area for a link
*/
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..561e6f0dfcb7 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -48,6 +48,13 @@ struct ocxl_ioctl_metadata {
__u64 reserved[13]; // Tot
_u64 reserved[13]; // Total of 16*u64
> };
>
> +struct ocxl_ioctl_p9_wait {
> + __u16 thread_id; // The thread ID required to wake this thread
> + __u16 reserved1;
> + __u32 reserved2;
> + __u64 reserved3[3];
> +};
> +
> +};
> +
O_o
???
cheers
a Process Element from the Shared Process Area for a link
*/
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..8d2748e69c84 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
__u64
a Process Element from the Shared Process Area for a link
*/
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..8d2748e69c84 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
__u64
xt
+ * tid: the new thread id for the process element
+ */
+extern int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
+
/*
* Remove a Process Element from the Shared Process Area for a link
*/
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..8d
/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..8d2748e69c84 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
__u64 reserved[13]; // Total of 16*u64
};
+struct ocxl_ioctl_p9_wait {
+ __u16 th
* Remove a Process Element from the Shared Process Area for a link
*/
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..8d2748e69c84 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
__u64
* Remove a Process Element from the Shared Process Area for a link
*/
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 0af83d80fb3e..8d2748e69c84 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
__u64
On Fri, 2005-07-15 at 11:39 +0530, RVK wrote:
> Understood on pid/tid and thread identifier diffrentiation. The question
> now is why pthread_t is typedef as unsigned long ?
It's just an arbitrary type that is big enough to contain the cookie.
Ian.
--
Ian Campbell
It is better to give than to
J.A. Magallon wrote:
On 07.14, RVK wrote:
Ian Campbell wrote:
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
Ian Campbell wrote:
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way, it is just a "thing" which yo
On 07.14, RVK wrote:
> Ian Campbell wrote:
>
> >On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
> >
> >
> >>Ian Campbell wrote:
> >>
> >>
> >>>What Arjan is saying is that pthread_t is a cookie -- this means that
> >>>you cannot interpret it in any way, it is just a "thing" which you can
> >>
RVK wrote:
Ian Campbell wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means
Jakub Jelinek wrote:
On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
pure luck. NPTL threading uses it to store a pointer to per thread info
structure; other threading (linuxthreads) may have stored a pid there to
identify the internal thread. nptl is 2.6 only so you might
> And you certainly shouldn't be using gettid () syscall in NPTL, as it
> is just an implementation detail that there is a 1:1 mapping between
> NPTL threads and kernel threads. It can change at any time.
Maybe I missed the point, but I thought the 1:1 mapping between NPTL
threads and kernel th
On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
> pure luck. NPTL threading uses it to store a pointer to per thread info
> structure; other threading (linuxthreads) may have stored a pid there to
> identify the internal thread. nptl is 2.6 only so you might have
> switched implem
> >
> So then what is the meaning of that typedef and why its still there ?
the typedef means that the *IMPLEMENTATION* uses an unsigned long to
store its cookie in.
>
> >Other implementations are allowed to use different types for this. In
> >fact, I'd be surprised if NPTL and LinuxThreads wou
Ian Campbell wrote:
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
Ian Campbell wrote:
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way, it is just a "thing" which you can
pass back to the API, that pthread_t happens to be typedef'
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
it doesn't return a number it returns a pointer ;) or a floating point
number. You don't know :)
what it returns is a *cookie*. A cookie that you can only use to pass
back to various pthread functions.
Hahaha.
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
> Ian Campbell wrote:
> >What Arjan is saying is that pthread_t is a cookie -- this means that
> >you cannot interpret it in any way, it is just a "thing" which you can
> >pass back to the API, that pthread_t happens to be typedef'd to unsigned
> >long
Ian Campbell wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means that
you c
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
> bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way,
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
> >
> >it doesn't return a number it returns a pointer ;) or a floating point
> >number. You don't know :)
> >
> >what it returns is a *cookie*. A cookie that you can only use to pass
> >back to various pthread functions.
> >
> >
> >
> Hahaha..co
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
Robert Hancock wrote:
RVK wrote:
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
What do you mean, negative integer? I
On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
> Robert Hancock wrote:
>
> > RVK wrote:
> >
> >> Can anyone suggest me how to get the threadId using 2.6.x kernels.
> >> pthread_self() does not work and returns some -ve integer.
> >
> >
> > What do you mean, negative integer? It's not an integer, it
Robert Hancock wrote:
RVK wrote:
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
What do you mean, negative integer? It's not an integer, it's a
pthread_t, you're not even supposed to look at it..
What is pthrea
You are right Bengettid() will do for me. Previously for 2.4.x
(2.4.18)thread libraries I normally was using pthread_self().
Raghu
Benedikt Spranger wrote:
Hi,
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
Hi,
> Can anyone suggest me how to get the threadId using 2.6.x kernels.
> pthread_self() does not work and returns some -ve integer.
Let me guess: You are looking for get_tid() :-)
Bene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
RVK wrote:
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
What do you mean, negative integer? It's not an integer, it's a
pthread_t, you're not even supposed to look at it..
--
Robert Hancock Saskatoon, SK, C
On Tue, 2005-07-05 at 17:45 +0530, RVK wrote:
> Can anyone suggest me how to get the threadId using 2.6.x kernels.
> pthread_self() does not work and returns some -ve integer.
NAME
pthread_self - get the calling thread ID
SYNOPSIS
#include
pthread_t pthread_self(void);
DE
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
thanks
rvk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
33 matches
Mail list logo
