[RFC PATCH 0/4] Export mqueues to procfs

[RFC PATCH 0/4] Export mqueues to procfs

[Florian Bezdeka]

Hi,

this is another try to make registered mqueues visible. This time by
exporting them to the procfs, namely to
/proc/xenomai/registry/mqueue/<name>

Let me know what you think... 

I had to rework the existing export machinery a bit to get rid of the so
called "root" directory which is normally created. See patch
descriptions for details.

Best regards,
Florian

Florian Bezdeka (4):
  cobalt/registry: Make the root directory for proc exports optional
  cobalt/registry: Share xnregistry_vfreg_ops with other compile units
  cobalt/registry: Initialize refcnt of exported virtual proc files
  cobalt/mqueue: Export created mqueues to procfs

 include/cobalt/kernel/registry.h |  2 ++
 kernel/cobalt/posix/mqueue.c     | 35 +++++++++++++++++++++++++++++++-
 kernel/cobalt/registry.c         | 13 ++++++------
 3 files changed, 43 insertions(+), 7 deletions(-)

-- 
2.30.2

[RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Florian Bezdeka]

Previously the root directory was mandatory, which means that exports
to the proc file system were forced to be located in
/proc/xenomai/registry/<root-dir>/<class>/<file>.

The <root-dir> virtual directory is now optional. If not supplied the
root node of <class> is set to registry_vfroot, which represents
/proc/xenomai/registry.

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 kernel/cobalt/registry.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
index fa1de66c3..5cbebdc5b 100644
--- a/kernel/cobalt/registry.c
+++ b/kernel/cobalt/registry.c
@@ -242,8 +242,8 @@ static void proc_callback(struct work_struct *work)
 		pnode = object->pnode;
 		type = pnode->dirname;
 		dir = &pnode->vdir;
-		rdir = &pnode->root->vdir;
-		rname = pnode->root->dirname;
+		rdir = pnode->root ? &pnode->root->vdir : &registry_vfroot;
+		rname = pnode->root ? pnode->root->dirname : NULL;
 
 		if (object->vfilp != XNOBJECT_EXPORT_SCHEDULED)
 			goto unexport;
@@ -254,7 +254,7 @@ static void proc_callback(struct work_struct *work)
 		xnlock_put_irqrestore(&nklock, s);
 
 		if (pnode->entries++ == 0) {
-			if (pnode->root->entries++ == 0) {
+			if (pnode->root && pnode->root->entries++ == 0) {
 				/* Create the root directory on the fly. */
 				ret = xnvfile_init_dir(rname, rdir, &registry_vfroot);
 				if (ret) {
@@ -268,7 +268,7 @@ static void proc_callback(struct work_struct *work)
 			/* Create the class directory on the fly. */
 			ret = xnvfile_init_dir(type, dir, rdir);
 			if (ret) {
-				if (pnode->root->entries == 1) {
+				if (pnode->root && pnode->root->entries == 1) {
 					pnode->root->entries = 0;
 					xnvfile_destroy_dir(rdir);
 				}
@@ -282,7 +282,7 @@ static void proc_callback(struct work_struct *work)
 		ret = pnode->ops->export(object, pnode);
 		if (ret && --pnode->entries == 0) {
 			xnvfile_destroy_dir(dir);
-			if (--pnode->root->entries == 0)
+			if (pnode->root && --pnode->root->entries == 0)
 				xnvfile_destroy_dir(rdir);
 			xnlock_get_irqsave(&nklock, s);
 			object->pnode = NULL;
@@ -315,7 +315,7 @@ static void proc_callback(struct work_struct *work)
 
 		if (--pnode->entries == 0) {
 			xnvfile_destroy_dir(dir);
-			if (--pnode->root->entries == 0)
+			if (pnode->root && --pnode->root->entries == 0)
 				xnvfile_destroy_dir(rdir);
 		}
 
-- 
2.30.2

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Philippe Gerum]

Florian Bezdeka via Xenomai <xenomai@xenomai.org> writes:

> Previously the root directory was mandatory, which means that exports
> to the proc file system were forced to be located in
> /proc/xenomai/registry/<root-dir>/<class>/<file>.
>
> The <root-dir> virtual directory is now optional. If not supplied the
> root node of <class> is set to registry_vfroot, which represents
> /proc/xenomai/registry.

This is not needed. You may want to try something along these lines
(excerpt from the Xenomai 2 implementation the registry originates from,
with a few adaptations for readability, ksrc/skins/native/queue.c):

static DEFINE_XNPTREE(__queue_ptree, "native");

static struct xnpnode_snapshot __q_pnode = {
	.node = {
		.dirname = "queues",
		.root = &__queue_ptree,
		.ops = &xnregistry_vfsnap_ops,
	},
	.vfile = {
		.privsz = sizeof(struct vfile_priv),
		.datasz = sizeof(struct vfile_data),
		.ops = &vfile_ops,
	},
};

...

xnregistry_enter(q->name, q, &q->handle, &__q_pnode.node);

With this, you would get the /proc/xenomai/registry/queues root
directory for queues created automatically, the way the registry wants
it to be done.

-- 
Philippe.

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Bezdeka, Florian]

On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote:
> Florian Bezdeka via Xenomai <xenomai@xenomai.org> writes:
> 
> > Previously the root directory was mandatory, which means that exports
> > to the proc file system were forced to be located in
> > /proc/xenomai/registry/<root-dir>/<class>/<file>.
> > 
> > The <root-dir> virtual directory is now optional. If not supplied the
> > root node of <class> is set to registry_vfroot, which represents
> > /proc/xenomai/registry.
> 
> This is not needed. You may want to try something along these lines
> (excerpt from the Xenomai 2 implementation the registry originates from,
> with a few adaptations for readability, ksrc/skins/native/queue.c):
> 
> static DEFINE_XNPTREE(__queue_ptree, "native");
> 
> static struct xnpnode_snapshot __q_pnode = {
> 	.node = {
> 		.dirname = "queues",
> 		.root = &__queue_ptree,
> 		.ops = &xnregistry_vfsnap_ops,
> 	},
> 	.vfile = {
> 		.privsz = sizeof(struct vfile_priv),
> 		.datasz = sizeof(struct vfile_data),
> 		.ops = &vfile_ops,
> 	},
> };
> 
> ...
> 
> xnregistry_enter(q->name, q, &q->handle, &__q_pnode.node);
> 
> With this, you would get the /proc/xenomai/registry/queues root
> directory for queues created automatically, the way the registry wants
> it to be done.
> 

I tried exactly that, but ended up all queues to be visible in
/proc/xenomai/registry/native/queues/<name> which was not what I wanted
to achieve.

But if you tell me that there must be an additional subdirectory, I'm
fine with it...

Florian

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Philippe Gerum]

Bezdeka, Florian <florian.bezdeka@siemens.com> writes:

> On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote:
>> Florian Bezdeka via Xenomai <xenomai@xenomai.org> writes:
>> 
>> > Previously the root directory was mandatory, which means that exports
>> > to the proc file system were forced to be located in
>> > /proc/xenomai/registry/<root-dir>/<class>/<file>.
>> > 
>> > The <root-dir> virtual directory is now optional. If not supplied the
>> > root node of <class> is set to registry_vfroot, which represents
>> > /proc/xenomai/registry.
>> 
>> This is not needed. You may want to try something along these lines
>> (excerpt from the Xenomai 2 implementation the registry originates from,
>> with a few adaptations for readability, ksrc/skins/native/queue.c):
>> 
>> static DEFINE_XNPTREE(__queue_ptree, "native");
>> 
>> static struct xnpnode_snapshot __q_pnode = {
>> 	.node = {
>> 		.dirname = "queues",
>> 		.root = &__queue_ptree,
>> 		.ops = &xnregistry_vfsnap_ops,
>> 	},
>> 	.vfile = {
>> 		.privsz = sizeof(struct vfile_priv),
>> 		.datasz = sizeof(struct vfile_data),
>> 		.ops = &vfile_ops,
>> 	},
>> };
>> 
>> ...
>> 
>> xnregistry_enter(q->name, q, &q->handle, &__q_pnode.node);
>> 
>> With this, you would get the /proc/xenomai/registry/queues root
>> directory for queues created automatically, the way the registry wants
>> it to be done.
>> 
>
> I tried exactly that, but ended up all queues to be visible in
> /proc/xenomai/registry/native/queues/<name> which was not what I wanted
> to achieve.
>
> But if you tell me that there must be an additional subdirectory, I'm
> fine with it...
>

DEFINE_XNPTREE(rtipc_ptree, "rtipc") already exists in the hierarchy,
with protocols attached underneath. The current registry still exhibits
some Xenomai 2 legacy, which would have one root per interface (native,
posix, vxworks etc.)

So, you could either graft your mqueue hierarchy directly under the
registry root the way your patch does, or reshuffle the whole thing a
bit in order to account for a new set of object families, like POSIX
(incl. mqueues), rtdm and other namespaces for some drivers if you plan
to export more objects in the future.

The point being that POSIX and RTDM for instance both implement
semaphores and threads. So either living with /proc/registry/posix_sema4
_and_ /proc/registry/rtdm_sema4 is ok with you, otherwise you may go for
keeping toplevel categories so as to have /proc/registry/posix/sema4 and
/proc/registry/rtdm/sema4.

-- 
Philippe.

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Bezdeka, Florian]

On Wed, 2021-08-18 at 16:02 +0200, Philippe Gerum wrote:
> Bezdeka, Florian <florian.bezdeka@siemens.com> writes:
> 
> > On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote:
> > > Florian Bezdeka via Xenomai <xenomai@xenomai.org> writes:
> > > 
> > > > Previously the root directory was mandatory, which means that exports
> > > > to the proc file system were forced to be located in
> > > > /proc/xenomai/registry/<root-dir>/<class>/<file>.
> > > > 
> > > > The <root-dir> virtual directory is now optional. If not supplied the
> > > > root node of <class> is set to registry_vfroot, which represents
> > > > /proc/xenomai/registry.
> > > 
> > > This is not needed. You may want to try something along these lines
> > > (excerpt from the Xenomai 2 implementation the registry originates from,
> > > with a few adaptations for readability, ksrc/skins/native/queue.c):
> > > 
> > > static DEFINE_XNPTREE(__queue_ptree, "native");
> > > 
> > > static struct xnpnode_snapshot __q_pnode = {
> > > 	.node = {
> > > 		.dirname = "queues",
> > > 		.root = &__queue_ptree,
> > > 		.ops = &xnregistry_vfsnap_ops,
> > > 	},
> > > 	.vfile = {
> > > 		.privsz = sizeof(struct vfile_priv),
> > > 		.datasz = sizeof(struct vfile_data),
> > > 		.ops = &vfile_ops,
> > > 	},
> > > };
> > > 
> > > ...
> > > 
> > > xnregistry_enter(q->name, q, &q->handle, &__q_pnode.node);
> > > 
> > > With this, you would get the /proc/xenomai/registry/queues root
> > > directory for queues created automatically, the way the registry wants
> > > it to be done.
> > > 
> > 
> > I tried exactly that, but ended up all queues to be visible in
> > /proc/xenomai/registry/native/queues/<name> which was not what I wanted
> > to achieve.
> > 
> > But if you tell me that there must be an additional subdirectory, I'm
> > fine with it...
> > 
> 
> DEFINE_XNPTREE(rtipc_ptree, "rtipc") already exists in the hierarchy,
> with protocols attached underneath. The current registry still exhibits
> some Xenomai 2 legacy, which would have one root per interface (native,
> posix, vxworks etc.)
> 
> So, you could either graft your mqueue hierarchy directly under the
> registry root the way your patch does, or reshuffle the whole thing a
> bit in order to account for a new set of object families, like POSIX
> (incl. mqueues), rtdm and other namespaces for some drivers if you plan
> to export more objects in the future.
> 
> The point being that POSIX and RTDM for instance both implement
> semaphores and threads. So either living with /proc/registry/posix_sema4
> _and_ /proc/registry/rtdm_sema4 is ok with you, otherwise you may go for
> keeping toplevel categories so as to have /proc/registry/posix/sema4 and
> /proc/registry/rtdm/sema4.
> 

Thanks a lot for the explanation. I wasn't aware that rtdm is providing
it's own semaphores. That's no problem for the mqueues in patch 4, but
as we still would need something similar for semaphores we would have
some kind of collision. 

So there is one single question open for me: What is the correct name
for the "root" directory in this case. "posix"?

I will resend a v2 which should consist of less patches. At least patch
1 (the one we are discussing here) should vanish.

Thanks!

Florian

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Jan Kiszka]

On 18.08.21 16:11, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Wed, 2021-08-18 at 16:02 +0200, Philippe Gerum wrote:
>> Bezdeka, Florian <florian.bezdeka@siemens.com> writes:
>>
>>> On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote:
>>>> Florian Bezdeka via Xenomai <xenomai@xenomai.org> writes:
>>>>
>>>>> Previously the root directory was mandatory, which means that exports
>>>>> to the proc file system were forced to be located in
>>>>> /proc/xenomai/registry/<root-dir>/<class>/<file>.
>>>>>
>>>>> The <root-dir> virtual directory is now optional. If not supplied the
>>>>> root node of <class> is set to registry_vfroot, which represents
>>>>> /proc/xenomai/registry.
>>>>
>>>> This is not needed. You may want to try something along these lines
>>>> (excerpt from the Xenomai 2 implementation the registry originates from,
>>>> with a few adaptations for readability, ksrc/skins/native/queue.c):
>>>>
>>>> static DEFINE_XNPTREE(__queue_ptree, "native");
>>>>
>>>> static struct xnpnode_snapshot __q_pnode = {
>>>>   .node = {
>>>>           .dirname = "queues",
>>>>           .root = &__queue_ptree,
>>>>           .ops = &xnregistry_vfsnap_ops,
>>>>   },
>>>>   .vfile = {
>>>>           .privsz = sizeof(struct vfile_priv),
>>>>           .datasz = sizeof(struct vfile_data),
>>>>           .ops = &vfile_ops,
>>>>   },
>>>> };
>>>>
>>>> ...
>>>>
>>>> xnregistry_enter(q->name, q, &q->handle, &__q_pnode.node);
>>>>
>>>> With this, you would get the /proc/xenomai/registry/queues root
>>>> directory for queues created automatically, the way the registry wants
>>>> it to be done.
>>>>
>>>
>>> I tried exactly that, but ended up all queues to be visible in
>>> /proc/xenomai/registry/native/queues/<name> which was not what I wanted
>>> to achieve.
>>>
>>> But if you tell me that there must be an additional subdirectory, I'm
>>> fine with it...
>>>
>>
>> DEFINE_XNPTREE(rtipc_ptree, "rtipc") already exists in the hierarchy,
>> with protocols attached underneath. The current registry still exhibits
>> some Xenomai 2 legacy, which would have one root per interface (native,
>> posix, vxworks etc.)
>>
>> So, you could either graft your mqueue hierarchy directly under the
>> registry root the way your patch does, or reshuffle the whole thing a
>> bit in order to account for a new set of object families, like POSIX
>> (incl. mqueues), rtdm and other namespaces for some drivers if you plan
>> to export more objects in the future.
>>
>> The point being that POSIX and RTDM for instance both implement
>> semaphores and threads. So either living with /proc/registry/posix_sema4
>> _and_ /proc/registry/rtdm_sema4 is ok with you, otherwise you may go for
>> keeping toplevel categories so as to have /proc/registry/posix/sema4 and
>> /proc/registry/rtdm/sema4.
>>
> 
> Thanks a lot for the explanation. I wasn't aware that rtdm is providing
> it's own semaphores. That's no problem for the mqueues in patch 4, but
> as we still would need something similar for semaphores we would have
> some kind of collision.

RTDM does have semaphores but those are not registered, specifically not
by any name.

Jan

> 
> So there is one single question open for me: What is the correct name
> for the "root" directory in this case. "posix"?
> 
> I will resend a v2 which should consist of less patches. At least patch
> 1 (the one we are discussing here) should vanish.
> 
> Thanks!
> 
> Florian
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [RFC PATCH 1/4] cobalt/registry: Make the root directory for proc exports optional

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 18.08.21 16:11, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
>> On Wed, 2021-08-18 at 16:02 +0200, Philippe Gerum wrote:
>>> Bezdeka, Florian <florian.bezdeka@siemens.com> writes:
>>>
>>>> On Wed, 2021-08-18 at 15:26 +0200, Philippe Gerum wrote:
>>>>> Florian Bezdeka via Xenomai <xenomai@xenomai.org> writes:
>>>>>
>>>>>> Previously the root directory was mandatory, which means that exports
>>>>>> to the proc file system were forced to be located in
>>>>>> /proc/xenomai/registry/<root-dir>/<class>/<file>.
>>>>>>
>>>>>> The <root-dir> virtual directory is now optional. If not supplied the
>>>>>> root node of <class> is set to registry_vfroot, which represents
>>>>>> /proc/xenomai/registry.
>>>>>
>>>>> This is not needed. You may want to try something along these lines
>>>>> (excerpt from the Xenomai 2 implementation the registry originates from,
>>>>> with a few adaptations for readability, ksrc/skins/native/queue.c):
>>>>>
>>>>> static DEFINE_XNPTREE(__queue_ptree, "native");
>>>>>
>>>>> static struct xnpnode_snapshot __q_pnode = {
>>>>>   .node = {
>>>>>           .dirname = "queues",
>>>>>           .root = &__queue_ptree,
>>>>>           .ops = &xnregistry_vfsnap_ops,
>>>>>   },
>>>>>   .vfile = {
>>>>>           .privsz = sizeof(struct vfile_priv),
>>>>>           .datasz = sizeof(struct vfile_data),
>>>>>           .ops = &vfile_ops,
>>>>>   },
>>>>> };
>>>>>
>>>>> ...
>>>>>
>>>>> xnregistry_enter(q->name, q, &q->handle, &__q_pnode.node);
>>>>>
>>>>> With this, you would get the /proc/xenomai/registry/queues root
>>>>> directory for queues created automatically, the way the registry wants
>>>>> it to be done.
>>>>>
>>>>
>>>> I tried exactly that, but ended up all queues to be visible in
>>>> /proc/xenomai/registry/native/queues/<name> which was not what I wanted
>>>> to achieve.
>>>>
>>>> But if you tell me that there must be an additional subdirectory, I'm
>>>> fine with it...
>>>>
>>>
>>> DEFINE_XNPTREE(rtipc_ptree, "rtipc") already exists in the hierarchy,
>>> with protocols attached underneath. The current registry still exhibits
>>> some Xenomai 2 legacy, which would have one root per interface (native,
>>> posix, vxworks etc.)
>>>
>>> So, you could either graft your mqueue hierarchy directly under the
>>> registry root the way your patch does, or reshuffle the whole thing a
>>> bit in order to account for a new set of object families, like POSIX
>>> (incl. mqueues), rtdm and other namespaces for some drivers if you plan
>>> to export more objects in the future.
>>>
>>> The point being that POSIX and RTDM for instance both implement
>>> semaphores and threads. So either living with /proc/registry/posix_sema4
>>> _and_ /proc/registry/rtdm_sema4 is ok with you, otherwise you may go for
>>> keeping toplevel categories so as to have /proc/registry/posix/sema4 and
>>> /proc/registry/rtdm/sema4.
>>>
>> 
>> Thanks a lot for the explanation. I wasn't aware that rtdm is providing
>> it's own semaphores. That's no problem for the mqueues in patch 4, but
>> as we still would need something similar for semaphores we would have
>> some kind of collision.
>
> RTDM does have semaphores but those are not registered, specifically not
> by any name.

Exporting them and other resources might further help debugging as
well. Adding a new interface for the user to provide a name should not
be an issue if such export is deemed useful eventually.

-- 
Philippe.

[RFC PATCH 2/4] cobalt/registry: Share xnregistry_vfreg_ops with other compile units

[Florian Bezdeka]

Allows re-using xnregistry_vfreg_ops. All other file options were
already available.

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 include/cobalt/kernel/registry.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/cobalt/kernel/registry.h b/include/cobalt/kernel/registry.h
index 624db5a78..a459da503 100644
--- a/include/cobalt/kernel/registry.h
+++ b/include/cobalt/kernel/registry.h
@@ -195,6 +195,8 @@ extern struct xnpnode_ops xnregistry_vfsnap_ops;
 
 extern struct xnpnode_ops xnregistry_vlink_ops;
 
+extern struct xnpnode_ops xnregistry_vfreg_ops;
+
 /** @} */
 
 #endif /* !_COBALT_KERNEL_REGISTRY_H */
-- 
2.30.2

[RFC PATCH 3/4] cobalt/registry: Initialize refcnt of exported virtual proc files

[Florian Bezdeka]

The refcnt field was never initialized and triggered a BUG() in
vfile_regular_release (vfile.c) when closing / releasing such a virtual
file.

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 kernel/cobalt/registry.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
index 5cbebdc5b..476254e65 100644
--- a/kernel/cobalt/registry.c
+++ b/kernel/cobalt/registry.c
@@ -403,6 +403,7 @@ static int registry_export_vfreg(struct xnobject *object,
 	object->vfile_u.vfreg.privsz = p->vfile.privsz;
 	object->vfile_u.vfreg.ops = p->vfile.ops;
 	object->vfile_u.vfreg.entry.lockops = p->vfile.lockops;
+	object->vfile_u.vfreg.entry.refcnt = 0;
 
 	ret = xnvfile_init_regular(object->key, &object->vfile_u.vfreg,
 				   &pnode->vdir);
-- 
2.30.2

[RFC PATCH 4/4] cobalt/mqueue: Export created mqueues to procfs

[Florian Bezdeka]

Exporting created mqueues to /proc/xenomai/registry/mqueue helps to
identify resource leaks by making mqueues visible. The content of all
created virtual files is empty. Removal of such files is not possible
and reports "operation not supported".

Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 kernel/cobalt/posix/mqueue.c | 35 ++++++++++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
index ebe7cf7b0..59d176491 100644
--- a/kernel/cobalt/posix/mqueue.c
+++ b/kernel/cobalt/posix/mqueue.c
@@ -87,6 +87,38 @@ static struct mq_attr default_attr = {
 
 static LIST_HEAD(cobalt_mqq);
 
+#ifdef CONFIG_XENO_OPT_VFILE
+
+static int mq_vfile_show(struct xnvfile_regular_iterator *it, void *data)
+{
+	return 0;
+}
+
+static struct xnvfile_regular_ops mq_vfile_ops = {
+	.show = mq_vfile_show,
+};
+
+static struct xnpnode_regular __mq_pnode = {
+	.node = {
+		.dirname = "mqueue",
+		.root = NULL,
+		.ops = &xnregistry_vfreg_ops,
+	},
+	.vfile = {
+		.ops = &mq_vfile_ops,
+	},
+};
+
+#else /* !CONFIG_XENO_OPT_VFILE */
+
+static struct xnpnode_link __iddp_pnode = {
+	.node = {
+		.dirname = "mqueue",
+	},
+};
+
+#endif /* !CONFIG_XENO_OPT_VFILE */
+
 static inline struct cobalt_msg *mq_msg_alloc(struct cobalt_mq *mq)
 {
 	if (list_empty(&mq->avail))
@@ -352,7 +384,8 @@ static int mq_open(int uqd, const char *name, int oflags,
 		}
 
 		xnlock_get_irqsave(&nklock, s);
-		err = xnregistry_enter(mq->name, mq, &mq->handle, NULL);
+		err = xnregistry_enter(mq->name, mq, &mq->handle,
+				       &__mq_pnode.node);
 		if (err < 0)
 			--mq->refs;
 		else
-- 
2.30.2

Re: [RFC PATCH 0/4] Export mqueues to procfs

[Jan Kiszka]

On 18.08.21 13:24, Florian Bezdeka wrote:
> Hi,
> 
> this is another try to make registered mqueues visible. This time by
> exporting them to the procfs, namely to
> /proc/xenomai/registry/mqueue/<name>
> 
> Let me know what you think... 
> 
> I had to rework the existing export machinery a bit to get rid of the so
> called "root" directory which is normally created. See patch
> descriptions for details.
> 
> Best regards,
> Florian
> 
> Florian Bezdeka (4):
>   cobalt/registry: Make the root directory for proc exports optional
>   cobalt/registry: Share xnregistry_vfreg_ops with other compile units
>   cobalt/registry: Initialize refcnt of exported virtual proc files
>   cobalt/mqueue: Export created mqueues to procfs
> 
>  include/cobalt/kernel/registry.h |  2 ++
>  kernel/cobalt/posix/mqueue.c     | 35 +++++++++++++++++++++++++++++++-
>  kernel/cobalt/registry.c         | 13 ++++++------
>  3 files changed, 43 insertions(+), 7 deletions(-)
> 

Will have a look.

We likely then also want the same for pshared semaphores, right?
Anything else that could get a name (which may collide or become orphaned)?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [RFC PATCH 0/4] Export mqueues to procfs

[Bezdeka, Florian]

On Wed, 2021-08-18 at 13:41 +0200, Jan Kiszka wrote:
> On 18.08.21 13:24, Florian Bezdeka wrote:
> > Hi,
> > 
> > this is another try to make registered mqueues visible. This time by
> > exporting them to the procfs, namely to
> > /proc/xenomai/registry/mqueue/<name>
> > 
> > Let me know what you think... 
> > 
> > I had to rework the existing export machinery a bit to get rid of the so
> > called "root" directory which is normally created. See patch
> > descriptions for details.
> > 
> > Best regards,
> > Florian
> > 
> > Florian Bezdeka (4):
> >   cobalt/registry: Make the root directory for proc exports optional
> >   cobalt/registry: Share xnregistry_vfreg_ops with other compile units
> >   cobalt/registry: Initialize refcnt of exported virtual proc files
> >   cobalt/mqueue: Export created mqueues to procfs
> > 
> >  include/cobalt/kernel/registry.h |  2 ++
> >  kernel/cobalt/posix/mqueue.c     | 35 +++++++++++++++++++++++++++++++-
> >  kernel/cobalt/registry.c         | 13 ++++++------
> >  3 files changed, 43 insertions(+), 7 deletions(-)
> > 
> 
> Will have a look.
> 
> We likely then also want the same for pshared semaphores, right?
> Anything else that could get a name (which may collide or become orphaned)?

Yes, to be complete we should do the same for shared semaphores. 

The previously submitted "dump patch" handled all registered types
(mqueue, semaphore, ...) the same way. But there was no type
information available. The registry holds the keys only.

> 
> Jan
>