* New IDX in linux/connector.h ?
@ 2008-07-23 12:40 Jerome Arbez-Gindre
2008-07-23 12:53 ` Evgeniy Polyakov
0 siblings, 1 reply; 4+ messages in thread
From: Jerome Arbez-Gindre @ 2008-07-23 12:40 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: linux-kernel, deweerdt
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New IDX in linux/connector.h ?
2008-07-23 12:40 New IDX in linux/connector.h ? Jerome Arbez-Gindre
@ 2008-07-23 12:53 ` Evgeniy Polyakov
2008-07-23 13:45 ` Jerome Arbez-Gindre
0 siblings, 1 reply; 4+ messages in thread
From: Evgeniy Polyakov @ 2008-07-23 12:53 UTC (permalink / raw)
To: Jerome Arbez-Gindre; +Cc: linux-kernel, deweerdt
Hi Jerome.
On Wed, Jul 23, 2008 at 02:40:29PM +0200, Jerome Arbez-Gindre (jeromearbezgindre@gmail.com) 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New IDX in linux/connector.h ?
2008-07-23 12:53 ` Evgeniy Polyakov
@ 2008-07-23 13:45 ` Jerome Arbez-Gindre
2008-07-23 14:04 ` Evgeniy Polyakov
0 siblings, 1 reply; 4+ messages in thread
From: Jerome Arbez-Gindre @ 2008-07-23 13:45 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: linux-kernel, deweerdt
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New IDX in linux/connector.h ?
2008-07-23 13:45 ` Jerome Arbez-Gindre
@ 2008-07-23 14:04 ` Evgeniy Polyakov
0 siblings, 0 replies; 4+ messages in thread
From: Evgeniy Polyakov @ 2008-07-23 14:04 UTC (permalink / raw)
To: Jerome Arbez-Gindre; +Cc: linux-kernel, deweerdt
On Wed, Jul 23, 2008 at 03:45:09PM +0200, Jerome Arbez-Gindre (jeromearbezgindre@gmail.com) 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-07-23 14:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-23 12:40 New IDX in linux/connector.h ? Jerome Arbez-Gindre
2008-07-23 12:53 ` Evgeniy Polyakov
2008-07-23 13:45 ` Jerome Arbez-Gindre
2008-07-23 14:04 ` Evgeniy Polyakov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®