All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Would an "information module" be useful?
Date: Sun, 22 Sep 2013 21:59:38 +0200	[thread overview]
Message-ID: <523F4C2A.3050207@nod.at> (raw)
In-Reply-To: <523F4A55.3090106@web.de>

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

  reply	other threads:[~2013-09-22 19:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-22 17:05 Would an "information module" be useful? Markus Elfring
2013-09-22 18:23 ` richard -rw- weinberger
2013-09-22 19:51   ` Markus Elfring
2013-09-22 19:59     ` Richard Weinberger [this message]
2013-09-22 20:30       ` Markus Elfring
2013-09-22 20:37         ` Richard Weinberger
2013-09-23  2:38           ` Markus Elfring
2013-09-23  5:47             ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=523F4C2A.3050207@nod.at \
    --to=richard@nod.at \
    --cc=Markus.Elfring@web.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.