Hi Evgeniy,
Nowadays, I'm working on a free software framework called TSP
(https://savannah.nongnu.org/p/tsp)
one of its components is a Blackboard (Aka BB).
It is simply a structured shared memory with named fields.
At the beginning, the BB was used to share/export data between two or
more userspace processes.
The blackboard also comes with messaging capabilities (which allows to
synchronize processes).
I'm working on a kernel port of the BB... and particularly on the
messaging feature.
My implementation is thus a user of your connector API
My request is the following:
Would it be possible to declare in linux/connector.h an IDX for the
BB, without any restriction on the VAL the BB could use?
We are willing to include the BB in-tree but this needs to be
discussed (in terms of usefulness) as the current kernel
implementation shares lots of code with the userspace implementations.
Thanks
Jerome
Hi Jerome.
On Wed, Jul 23, 2008 at 02:40:29PM +0200, Jerome Arbez-Gindre ([email protected]) wrote:
> Would it be possible to declare in linux/connector.h an IDX for the
> BB, without any restriction on the VAL the BB could use?
Sure.
VAL (which is 'value' of course) is a private 'offset' inside given
index (IDX), so when you register single IDX all corresponding VALs
belong to the same user.
And some side notes.
I even wanted to have private indexes, i.e. those which are supposed to
be used by out-of-the-tree code, and no in-kernel users would ever touch
this numbers.
You actually can use your own private numbers as long they do not
correspond to currently loaded callbacks. Number of users in the header
is actually a hint, it does not play any role at all as long as number
of users is smaller than 32 (kernel stack allocates this bitmask by
default even if number of users/sockets is smaller).
There is also connector's itself own index (-1), used for requesting a
notifications about new connector users registrations, it can be
simply enough extended to provide dynamic index assignment.
--
Evgeniy Polyakov
Hi Evgeniy,
>> Would it be possible to declare in linux/connector.h an IDX for the
>> BB, without any restriction on the VAL the BB could use?
>
> Sure.
> VAL (which is 'value' of course) is a private 'offset' inside given
> index (IDX), so when you register single IDX all corresponding VALs
> belong to the same user.
I meant:
diff --git a/include/linux/connector.h b/include/linux/connector.h
index 96a89d3..361996c 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -38,6 +38,7 @@
#define CN_W1_VAL 0x1
#define CN_IDX_V86D 0x4
#define CN_VAL_V86D_UVESAFB 0x1
+#define CN_IDX_BB 0x5
#define CN_NETLINK_USERS 5
> I even wanted to have private indexes, i.e. those which are supposed to
> be used by out-of-the-tree code, and no in-kernel users would ever touch
> this numbers.
So which numbers am I suppose to use ... taking account that BB will
probably stay for a long time out-of-the-tree ?
Thanks
Jerome Arbez-Gindre
On Wed, Jul 23, 2008 at 03:45:09PM +0200, Jerome Arbez-Gindre ([email protected]) wrote:
> diff --git a/include/linux/connector.h b/include/linux/connector.h
> index 96a89d3..361996c 100644
> --- a/include/linux/connector.h
> +++ b/include/linux/connector.h
> @@ -38,6 +38,7 @@
> #define CN_W1_VAL 0x1
> #define CN_IDX_V86D 0x4
> #define CN_VAL_V86D_UVESAFB 0x1
> +#define CN_IDX_BB 0x5
>
> #define CN_NETLINK_USERS 5
Update this number too.
While it is less than 32, it does not matter, but just for the record.
> > I even wanted to have private indexes, i.e. those which are supposed to
> > be used by out-of-the-tree code, and no in-kernel users would ever touch
> > this numbers.
>
> So which numbers am I suppose to use ... taking account that BB will
> probably stay for a long time out-of-the-tree ?
You can use whatever VAL number you like:
struct cb_id cn_dst_id[] = {{CN_DST_IDX, 1}, {CN_DST_IDX, 2}, {CN_DST_IDX, 3}};
for (i=0; i<ARRAY_SIZE(cn_dst_id); ++i)
cn_add_callback(&cn_dst_id[i], "DST", cn_dst_callback_func);
So cn_dst_callback_func() will be invoked for
idx=CN_DST_IDX,val={1,2,3}, you can determine val parameter from the
provided header and make appropriate decition.
You can also register multiple different callbacks for each idx.val
pair of course.
--
Evgeniy Polyakov