Would an "information module" be useful?

Would an "information module" be useful?

[Markus Elfring]

Hello,

I became interested in an use case where I want to pass customised data from the
boot command-line to other user processes. I have read the available
documentation in the way that kernel modules provide such a means to get
additional parameters recorded.

I have got the understanding that a kernel module provides also a name space for
such boot parameters. (Are they also called "attributes" there?)
Now I would be interested to create a module for my needs so that the passed
data will be stored in the sys file system. Which software component is
responsible for this task?

I find that another implementation detail needs more clarification. The modules
usually drive some hardware.
https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt

But I am looking for a kind of kernel module which does not serve any hardware.
I imagine that it should be sufficient to register it as a simple information sink.

How do you think about my considerations?
Would you like to share any alternative ideas?

Regards,
Markus

Re: Would an "information module" be useful?

[richard -rw- weinberger]

On Sun, Sep 22, 2013 at 7:05 PM, Markus Elfring <Markus.Elfring@web.de> wrote:
> Hello,
>
> I became interested in an use case where I want to pass customised data from the
> boot command-line to other user processes. I have read the available
> documentation in the way that kernel modules provide such a means to get
> additional parameters recorded.
>
> I have got the understanding that a kernel module provides also a name space for
> such boot parameters. (Are they also called "attributes" there?)
> Now I would be interested to create a module for my needs so that the passed
> data will be stored in the sys file system. Which software component is
> responsible for this task?
>
> I find that another implementation detail needs more clarification. The modules
> usually drive some hardware.
> https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt
>
> But I am looking for a kind of kernel module which does not serve any hardware.
> I imagine that it should be sufficient to register it as a simple information sink.
>
> How do you think about my considerations?
> Would you like to share any alternative ideas?

Why can't you use /proc/cmdline?
systemd for example parses /proc/cmdline by looking at keys like "systemd.*=".
(see parse_proc_cmdline())

-- 
Thanks,
//richard

Re: Would an "information module" be useful?

[Markus Elfring]

> Why can't you use /proc/cmdline?

Thanks for your suggestion.


> (see parse_proc_cmdline())

How do you think about reasons like the following?

1. I would prefer to avoid the repeated parsing of boot command-line parameters
because the reuse of the kernel infrastructure should be better here.

2. Documentation
   Module parameters can also be explained in the source files.
   http://tldp.org/LDP/lkmpg/2.6/html/x323.html

3. Is a corresponding check for specific data types "nice"?
   http://www.linux-magazin.de/Ausgaben/2004/05/Kern-Technik/%28offset%29/2



How are the chances to clarify this implementation detail: In which subdirectory
should a kernel module be stored if it will not manage any hardware?

Regards,
Markus

Re: Would an "information module" be useful?

[Richard Weinberger]

Markus,

Am 22.09.2013 21:51, schrieb Markus Elfring:
>> Why can't you use /proc/cmdline?
> 
> Thanks for your suggestion.
> 
> 
>> (see parse_proc_cmdline())
> 
> How do you think about reasons like the following?
> 
> 1. I would prefer to avoid the repeated parsing of boot command-line parameters
> because the reuse of the kernel infrastructure should be better here.
> 
> 2. Documentation
>    Module parameters can also be explained in the source files.
>    http://tldp.org/LDP/lkmpg/2.6/html/x323.html
> 
> 3. Is a corresponding check for specific data types "nice"?
>    http://www.linux-magazin.de/Ausgaben/2004/05/Kern-Technik/%28offset%29/2
> 

Yeah, but there is one big issue.
You can do all parsing in user space too.
There is no need to add code to the kernel...
The kernel itself also simply parses the cmdline[] variable.

> 
> How are the chances to clarify this implementation detail: In which subdirectory
> should a kernel module be stored if it will not manage any hardware?

Of course you can hack such a module for your own usage. But I'm sure it will not get merged.
All you need is a dummy module with a few module_param()s. You can find them later in
/sys/module/<name of your module>/parameters/.

drivers/misc/ is a nice place do dump such things. :-)

Thanks,
//richard

Re: Would an "information module" be useful?

[Markus Elfring]

> You can do all parsing in user space too.

Is it questionable when a custom prefix of a boot command-line parameter can not
be mapped to a kernel module?


> But I'm sure it will not get merged.

Thanks for your feedback.


> All you need is a dummy module with a few module_param()s.

My ideas went in such a direction.


> drivers/misc/ is a nice place do dump such things. :-)

Is an information sink module (with corresponding data type checks) still an
"ordinary" driver?

Regards,
Markus

Re: Would an "information module" be useful?

[Richard Weinberger]

Am 22.09.2013 22:30, schrieb Markus Elfring:
>> You can do all parsing in user space too.
> 
> Is it questionable when a custom prefix of a boot command-line parameter can not
> be mapped to a kernel module?

No.
In the systemd case we have to ensure that we never ever merge a module named "systemd".
It's that easy. :)

>> drivers/misc/ is a nice place do dump such things. :-)
> 
> Is an information sink module (with corresponding data type checks) still an
> "ordinary" driver?

We have all kinds of strange modules/drivers. Usually you don't have to think whether your
module is a "ordinary" driver or not...
See drivers/misc/dummy-irq.c.

Thanks,
//richard

Re: Would an "information module" be useful?

[Markus Elfring]

> In the systemd case we have to ensure that we never ever merge a module named "systemd".

Interesting ...


> We have all kinds of strange modules/drivers. Usually you don't have to think
> whether your module is a "ordinary" driver or not...

Would it become useful to move "drivers" which do not manage hardware to a
separate directory?
Should such source files belong to a different software category (or "class")?

Regards,
Markus

Re: Would an "information module" be useful?

[Richard Weinberger]

Markus,

Am 23.09.2013 04:38, schrieb Markus Elfring:
> Would it become useful to move "drivers" which do not manage hardware to a
> separate directory?
> Should such source files belong to a different software category (or "class")?

IMHO it would be not very useful.
We have more serious issues to solve. :-)

Thanks,
//richard