* [Xenomai-core] [PATCH] let skins select nucleus features
@ 2006-04-13 18:34 Jan Kiszka
2006-04-16 17:01 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2006-04-13 18:34 UTC (permalink / raw)
To: xenomai-core
[-- Attachment #1.1: Type: text/plain, Size: 363 bytes --]
Hi,
this patch aims at avoiding to select unneeded nucleus features if no
user is requiring it in the skins. Particularly, it addresses the
nucleus registry and the pipes.
I have spent no effort on 2.4 yet as I first want to wait for comments.
Furthermore, 2.4. is lacking "select", so the feature selection has to
remain manually there anyway.
Jan
[-- Attachment #1.2: nucleus-features.patch --]
[-- Type: text/plain, Size: 3882 bytes --]
Index: ksrc/nucleus/Kconfig
===================================================================
--- ksrc/nucleus/Kconfig (revision 924)
+++ ksrc/nucleus/Kconfig (working copy)
@@ -32,15 +32,7 @@ config XENO_OPT_SECURITY_ACCESS
think twice before switching this off.
config XENO_OPT_PIPE
- bool "Message pipes"
- default y
- help
-
- Message pipes are bi-directional FIFO communication
- channels allowing data exchange between real-time kernel
- threads and regular user-space processes. Pipes natively
- preserve message boundaries, but can also be used in byte
- streaming mode from kernel to user-space.
+ bool
config XENO_OPT_PIPE_NRDEV
int "Number of pipe devices"
@@ -48,14 +40,23 @@ config XENO_OPT_PIPE_NRDEV
default 32
help
+ Message pipes are bi-directional FIFO communication
+ channels allowing data exchange between real-time kernel
+ threads and regular user-space processes. Pipes natively
+ preserve message boundaries, but can also be used in byte
+ streaming mode from kernel to user-space.
+
This option sets the maximum number of pipe devices supported
in the system. Pipe devices are named /dev/rtpN where N is a
device minor number ranging from 0 to XENO_OPT_PIPE_NRDEV - 1.
config XENO_OPT_REGISTRY
bool
- prompt "Registry support" if !XENO_OPT_PERVASIVE
- default y
+
+config XENO_OPT_REGISTRY_NRSLOTS
+ int "Number of registry slots"
+ depends on XENO_OPT_REGISTRY
+ default 512
help
The registry is used by Xenomai skins to bind real-time
@@ -63,12 +64,6 @@ config XENO_OPT_REGISTRY
can be further retrieved and shared by real-time applications
regardless of their runtime space (i.e. kernel or user). Each
named object occupies a registry slot.
-
-config XENO_OPT_REGISTRY_NRSLOTS
- int "Number of registry slots"
- depends on XENO_OPT_REGISTRY
- default 512
- help
This option sets the maximum number of real-time objects the
registry can handle. All skins using the registry share this
Index: ksrc/skins/vrtx/Kconfig
===================================================================
--- ksrc/skins/vrtx/Kconfig (revision 924)
+++ ksrc/skins/vrtx/Kconfig (working copy)
@@ -1,7 +1,7 @@
config XENO_SKIN_VRTX
depends on XENO_OPT_NUCLEUS
tristate "VRTX emulator"
- default n
+ select XENO_OPT_REGISTRY
help
This API skin emulates Mentor Graphics's VRTX operating
Index: ksrc/skins/vxworks/Kconfig
===================================================================
--- ksrc/skins/vxworks/Kconfig (revision 924)
+++ ksrc/skins/vxworks/Kconfig (working copy)
@@ -1,7 +1,7 @@
config XENO_SKIN_VXWORKS
depends on XENO_OPT_NUCLEUS
tristate "VxWorks emulator"
- default n
+ select XENO_OPT_REGISTRY
help
This API skin emulates WindRiver's VxWorks operating system.
Index: ksrc/skins/native/Kconfig
===================================================================
--- ksrc/skins/native/Kconfig (revision 924)
+++ ksrc/skins/native/Kconfig (working copy)
@@ -10,7 +10,7 @@ if XENO_SKIN_NATIVE != n
config XENO_OPT_NATIVE_PIPE
bool "Message pipes"
- depends on XENO_OPT_PIPE
+ select XENO_OPT_PIPE
default y
help
@@ -33,6 +33,18 @@ config XENO_OPT_NATIVE_PIPE_BUFSZ
This option sets the memory size available for per-pipe
buffering when message pipes are used in byte stream mode.
+config XENO_OPT_NATIVE_REGISTRY
+ bool
+ prompt "Registry support" if !XENO_OPT_PERVASIVE
+ select XENO_OPT_REGISTRY
+ default y
+ help
+
+ The registry is used to bind real-time objects to symbolic names,
+ so that these objects can be further retrieved and shared by
+ real-time applications regardless of their runtime space (i.e.
+ kernel or user). Each named object occupies a registry slot.
+
config XENO_OPT_NATIVE_SEM
bool "Counting semaphores"
default y
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [PATCH] let skins select nucleus features
2006-04-13 18:34 [Xenomai-core] [PATCH] let skins select nucleus features Jan Kiszka
@ 2006-04-16 17:01 ` Philippe Gerum
2006-04-17 22:42 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2006-04-16 17:01 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
Jan Kiszka wrote:
> Hi,
>
> this patch aims at avoiding to select unneeded nucleus features if no
> user is requiring it in the skins. Particularly, it addresses the
> nucleus registry and the pipes.
>
> I have spent no effort on 2.4 yet as I first want to wait for comments.
> Furthermore, 2.4. is lacking "select", so the feature selection has to
> remain manually there anyway.
Looks good. Merged, thanks.
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [PATCH] let skins select nucleus features
2006-04-16 17:01 ` Philippe Gerum
@ 2006-04-17 22:42 ` Jan Kiszka
2006-04-18 10:50 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2006-04-17 22:42 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> this patch aims at avoiding to select unneeded nucleus features if no
>> user is requiring it in the skins. Particularly, it addresses the
>> nucleus registry and the pipes.
>>
>> I have spent no effort on 2.4 yet as I first want to wait for comments.
>> Furthermore, 2.4. is lacking "select", so the feature selection has to
>> remain manually there anyway.
>
> Looks good. Merged, thanks.
>
In the same sense, but not that comfortable, here is the a 2.4 variant
of the patch.
Jan
[-- Attachment #2: nucl-reg-select-2.4.patch --]
[-- Type: text/x-patch, Size: 2294 bytes --]
Index: ksrc/skins/vrtx/Config.in
===================================================================
--- ksrc/skins/vrtx/Config.in (Revision 941)
+++ ksrc/skins/vrtx/Config.in (Arbeitskopie)
@@ -2,4 +2,10 @@
# Xenomai configuration for Linux v2.4
#
+if [ "$CONFIG_XENO_OPT_REGISTRY" = "n" ]; then
+ comment 'VRTX emulator requires CONFIG_XENO_OPT_REGISTRY'
+else
+
dep_tristate 'VRTX emulator' CONFIG_XENO_SKIN_VRTX $CONFIG_XENO_OPT_NUCLEUS
+
+fi
Index: ksrc/skins/vxworks/Config.in
===================================================================
--- ksrc/skins/vxworks/Config.in (Revision 941)
+++ ksrc/skins/vxworks/Config.in (Arbeitskopie)
@@ -2,4 +2,10 @@
# Xenomai configuration for Linux v2.4
#
+if [ "$CONFIG_XENO_OPT_REGISTRY" = "n" ]; then
+ comment 'VxWorks emulator requires CONFIG_XENO_OPT_REGISTRY'
+else
+
dep_tristate 'VxWorks emulator' CONFIG_XENO_SKIN_VXWORKS $CONFIG_XENO_OPT_NUCLEUS
+
+fi
Index: ksrc/skins/native/Config.in
===================================================================
--- ksrc/skins/native/Config.in (Revision 941)
+++ ksrc/skins/native/Config.in (Arbeitskopie)
@@ -2,6 +2,10 @@
# Xenomai configuration for Linux v2.4
#
+if [ "$CONFIG_XENO_OPT_PERVASIVE" = "y" -a "$CONFIG_XENO_OPT_REGISTRY" = "n" ]; then
+ comment 'Native skin requires CONFIG_XENO_OPT_REGISTRY in pervasive mode'
+else
+
dep_tristate 'Native skin' CONFIG_XENO_SKIN_NATIVE $CONFIG_XENO_OPT_NUCLEUS
if [ "$CONFIG_XENO_SKIN_NATIVE" != "n" ]; then
@@ -24,3 +28,5 @@ if [ "$CONFIG_XENO_SKIN_NATIVE" != "n" ]
bool 'Interrupts' CONFIG_XENO_OPT_NATIVE_INTR
endmenu
fi
+
+fi
Index: ksrc/nucleus/Config.in
===================================================================
--- ksrc/nucleus/Config.in (Revision 941)
+++ ksrc/nucleus/Config.in (Arbeitskopie)
@@ -17,11 +17,7 @@ if [ "$CONFIG_XENO_OPT_NUCLEUS" != "n" ]
if [ "$CONFIG_XENO_OPT_PIPE" != "n" ]; then
int 'Number of pipe devices' CONFIG_XENO_OPT_PIPE_NRDEV 32
fi
- if [ "$CONFIG_XENO_OPT_PERVASIVE" != "n" ]; then
- define_bool CONFIG_XENO_OPT_REGISTRY y
- else
- bool 'Registry support' CONFIG_XENO_OPT_REGISTRY
- fi
+ bool 'Registry support' CONFIG_XENO_OPT_REGISTRY
if [ "$CONFIG_XENO_OPT_REGISTRY" != "n" ]; then
int 'Number of registry slots' CONFIG_XENO_OPT_REGISTRY_NRSLOTS 512
fi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [PATCH] let skins select nucleus features
2006-04-17 22:42 ` Jan Kiszka
@ 2006-04-18 10:50 ` Philippe Gerum
2006-04-18 12:14 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2006-04-18 10:50 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
Jan Kiszka wrote:
> Philippe Gerum wrote:
>
>>Jan Kiszka wrote:
>>
>>>Hi,
>>>
>>>this patch aims at avoiding to select unneeded nucleus features if no
>>>user is requiring it in the skins. Particularly, it addresses the
>>>nucleus registry and the pipes.
>>>
>>>I have spent no effort on 2.4 yet as I first want to wait for comments.
>>>Furthermore, 2.4. is lacking "select", so the feature selection has to
>>>remain manually there anyway.
>>
>>Looks good. Merged, thanks.
>>
>
>
> In the same sense, but not that comfortable, here is the a 2.4 variant
> of the patch.
I don't agree with the logic of this patch. All user-space enabled skins
may also run in pure kernel-space in non pervasive mode. A core
dependency exists from CONFIG_XENO_OPT_REGISTRY on
CONFIG_XENO_OPT_PERVASIVE, and it should be defined explicitely. In any
case, maybe it's not worth trying to be too smart with the 2.4
configuration system when it comes to dealing with features
inter-dependencies, since we really miss the proper support to do that.
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [PATCH] let skins select nucleus features
2006-04-18 10:50 ` Philippe Gerum
@ 2006-04-18 12:14 ` Jan Kiszka
2006-04-18 12:20 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2006-04-18 12:14 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Hi,
>>>>
>>>> this patch aims at avoiding to select unneeded nucleus features if no
>>>> user is requiring it in the skins. Particularly, it addresses the
>>>> nucleus registry and the pipes.
>>>>
>>>> I have spent no effort on 2.4 yet as I first want to wait for comments.
>>>> Furthermore, 2.4. is lacking "select", so the feature selection has to
>>>> remain manually there anyway.
>>>
>>> Looks good. Merged, thanks.
>>>
>>
>>
>> In the same sense, but not that comfortable, here is the a 2.4 variant
>> of the patch.
>
> I don't agree with the logic of this patch. All user-space enabled skins
> may also run in pure kernel-space in non pervasive mode. A core
> dependency exists from CONFIG_XENO_OPT_REGISTRY on
> CONFIG_XENO_OPT_PERVASIVE, and it should be defined explicitely. In any
> case, maybe it's not worth trying to be too smart with the 2.4
> configuration system when it comes to dealing with features
> inter-dependencies, since we really miss the proper support to do that.
>
Sorry, doesn't parse for me yet. You that when CONFIG_XENO_OPT_PERVASIVE
is enabled CONFIG_XENO_OPT_REGISTRY is required (which was not correct,
see POSIX skin)?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-core] [PATCH] let skins select nucleus features
2006-04-18 12:14 ` Jan Kiszka
@ 2006-04-18 12:20 ` Philippe Gerum
0 siblings, 0 replies; 6+ messages in thread
From: Philippe Gerum @ 2006-04-18 12:20 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
Jan Kiszka wrote:
> Philippe Gerum wrote:
>
>>Jan Kiszka wrote:
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>Jan Kiszka wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>this patch aims at avoiding to select unneeded nucleus features if no
>>>>>user is requiring it in the skins. Particularly, it addresses the
>>>>>nucleus registry and the pipes.
>>>>>
>>>>>I have spent no effort on 2.4 yet as I first want to wait for comments.
>>>>>Furthermore, 2.4. is lacking "select", so the feature selection has to
>>>>>remain manually there anyway.
>>>>
>>>>Looks good. Merged, thanks.
>>>>
>>>
>>>
>>>In the same sense, but not that comfortable, here is the a 2.4 variant
>>>of the patch.
>>
>>I don't agree with the logic of this patch. All user-space enabled skins
>>may also run in pure kernel-space in non pervasive mode. A core
>>dependency exists from CONFIG_XENO_OPT_REGISTRY on
>>CONFIG_XENO_OPT_PERVASIVE, and it should be defined explicitely. In any
>>case, maybe it's not worth trying to be too smart with the 2.4
>>configuration system when it comes to dealing with features
>>inter-dependencies, since we really miss the proper support to do that.
>>
>
>
> Sorry, doesn't parse for me yet. You that when CONFIG_XENO_OPT_PERVASIVE
> is enabled CONFIG_XENO_OPT_REGISTRY is required (which was not correct,
> see POSIX skin)?
The POSIX skin is an exception, since it implemented its own registry
support before the native registry was moved as a generic nucleus
feature; at some point in time, the POSIX registry should be rebased on
the nucleus support. We must now consider that having
CONFIG_XENO_OPT_PERVASIVE set requires CONFIG_XENO_OPT_REGISTRY to be
set too. OTOH, you can have CONFIG_XENO_OPT_REGISTRY set without
CONFIG_XENO_OPT_PERVASIVE, if you want to run skins in kernel space
only, whilst still providing registry support for inter-modules requests.
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-04-18 12:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-13 18:34 [Xenomai-core] [PATCH] let skins select nucleus features Jan Kiszka
2006-04-16 17:01 ` Philippe Gerum
2006-04-17 22:42 ` Jan Kiszka
2006-04-18 10:50 ` Philippe Gerum
2006-04-18 12:14 ` Jan Kiszka
2006-04-18 12:20 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.