A couple of boot command-line parameters are documented. Short numbers and strings are mostly specified for corresponding settings.
On 2013-09-21 11:46, elfring wrote:
>
> A couple of ‘boot command-line parameters are documented’
> (http://files.kroah.com/lkn/lkn_pdf/ch09.pdf). Short numbers and strings
> are mostly specified for corresponding settings.
>
> - Can also file contents be passed by customised parameters there?
I doubt it.
> - Are there any limitations that should be considered for usable data
> sizes?
Whatever the respective documentation says.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Your doubts might vary with different file sizes. I hope that alternative data structures can also be passed besides the values which are categorised as usual at the moment. I imagine to pass values in formats like XML and JSON, too.
Whatever the respective documentation says.
Do you know any documentation which limits the amount of data that can be used for boot command-line parameters?
Would you like to refer to any concrete storage constraints?
Kernel parameters are used to interface with internal kernel controls, not anything else. So I don’t see your point.
Passing random stuff may or may not crash the kernel. The kernel knows nothing about what comes next in the boot other then to call it and there are numerous different init stratagems so not knowing exactly what those init process what or require there is a limited amount of things you can pass.
I agree to such a view usually.
So I don’t see your point.
I am also interested in the creation of a kernel module for an other purpose. A customised module can get dedicated parameters.
I imagine that a module like “additional_boot_info” (or “add_binfo”) would be useful for the forwarding of specific settings.
Passing random stuff may or may not crash the kernel.
I find that such a general description needs more considerations.
… there is a limited amount of things you can pass.
But the acceptable parameter set is extensible according to appropriate module selection, isn’t it?
On 2013-09-22 00:16, elfring wrote:
>> … there is a limited amount of things you can pass.
> But the acceptable parameter set is extensible according to appropriate
> module selection, isn’t it?
Remember that at that time the filesystems are not mounted, so files can
not be read. All data and programs needed early are passed inside initrd.
Anyway, your question seems too complex for a users forum, you need to
ask kernel people.
There is a kernel mail list at openSUSE, for instance.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Greg Kroah-Hartman provided a bit more information about such an aspect in the article “Driving Me Nuts - Things You Never Should Do in the Kernel”. 
All data and programs needed early are passed inside initrd.
Do all parameters from the boot command-line get stored in the sys file system before Linux will try to start its first program?
Anyway, your question seems too complex for a users forum, you need
to ask kernel people.
I hope that constructive discussions can also evolve here around the presented ideas.
On 2013-09-22 08:56, elfring wrote:
>> Anyway, your question seems too complex for a users forum, you need
>> to ask kernel people.
> I hope that constructive discussions can also evolve here around the
> presented ideas.
I don’t know enough about the kernel to answer your questions.
What I know is that I’ve never seen a file passed as parameter to the
kernel, nor seen it in the parameter documentation included with the
sources. I’ve never seen it in my 15 years Linux experience, but then,
I’m not a kernel developer.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
A (binary) file can not be passed directly because it might contain special characters (like spaces) which do not fit to the grammar of boot command-line parameters. (Multi-line strings might also be questionable for corresponding attributes.)
But I imagine that the needed file content can also be converted to a data format like Base64.
I’ve never seen it in my 15 years Linux experience, but then,
I’m not a kernel developer.
Thanks for your feedback.
Are you interested in the passing of additional boot information which could be used for improved dynamic configuration of services like display servers?
On 2013-09-22 12:46, elfring wrote:
> Are you interested in the passing of additional boot information which
> could be used for improved dynamic configuration of services like
> display servers?
No, sorry.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 09/22/2013 07:28 AM, Carlos E. R. wrote:
> On 2013-09-22 12:46, elfring wrote:
>
>> Are you interested in the passing of additional boot information which
>> could be used for improved dynamic configuration of services like
>> display servers?
>
> No, sorry.
Until the kernel is completely up and running, there are no user-space programs
running. Most of the info on the command line is used to control kernel modules
and their operation. Of course, only the commands that the module’s author has
enabled are appropriate.
Do you know any module eventually which does not drive hardware?
Can it only be used as a simple information sink for the discussed use case?
On 09/22/2013 10:16 AM, elfring wrote:
>
> lwfinger;2586809 Wrote:
>> Most of the info on the command line is used to control kernel modules
>> and their operation.
> Do you know any module eventually which does not drive hardware?
> Can it only be used as a simple information sink for the discussed use
> case?
You could certainly write a module that could absorb information from the
command line and publish it in a file in the /sys tree where it could be read by
a user program, or by another part of the kernel. At present, there are no such
modules that I know about.
On 09/23/2013 04:46 AM, elfring wrote:
>
> lwfinger;2586945 Wrote:
>> You could certainly write a module that could absorb information from
>> the
>> command line and publish it in a file in the /sys tree where it could be
>> read by
>> a user program, or by another part of the kernel.
> I mentioned such an approach also on ‘a well-known mailing list’
> (https://lkml.org/lkml/2013/9/22/143).
Your one respondent seems to think that the module you are proposing would never
be merged, but you never know until you try. BTW, I never saw you explain why
/proc/cmdline would not work.
Direct reuse of the boot command-line data might also work with this file. I see it as a matter for consistency if a kernel module would extract a few parameters from there to attributes in the sys file system by a documented process.
Do you know a published grammar for this “command-line”?
On 09/23/2013 08:36 AM, elfring wrote:
>
> lwfinger;2587043 Wrote:
>> BTW, I never saw you explain why /proc/cmdline would not work.
> Direct reuse of the boot command-line data might also work with this
> file. I see it as a matter for consistency if a kernel module would
> extract a few parameters from there to attributes in the sys file system
> by a documented process.
> Do you know a published grammar for this “command-line”?
It is a set of tokens separated by spaces with input values after an equal sign.
It is just the line passed to the kernel by whatever boot manager you are using.
The kernel will pick up any keywords that it recognizes and skip whatever it
does not.
My current one is
finger@larrylap:~/wireless-testing-save> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.12.0-rc1-wl+
root=UUID=569e7933-a06e-4ec9-88a8-2581adca98ad nomodeset
resume=/dev/disk/by-id/ata-ST9250315AS_5VC2GXQZ-part3 splash=silent quiet
showopts crashkernel=128M
finger@larrylap:~/wireless-testing-save>
I know that in principle, too. But I would like to be sure how the assigned strings should be treated if they are “optionally” enclosed by single or double quotes.
I find that the corresponding parsing would be easier and safer if a grammar would be freely available in a format like EBNF or Bison.
On 09/23/2013 03:06 PM, elfring wrote:
>
> lwfinger;2587118 Wrote:
>> It is a set of tokens separated by spaces with input values after an
>> equal sign.
> I know that in principle, too. But I would like to be sure how the
> assigned strings should be treated if they are “optionally” enclosed by
> single or double quotes.
>
> I find that the corresponding parsing would be easier and safer if a
> grammar would be freely available in a format like ‘EBNF’
> (http://en.wikipedia.org/wiki/Extended_Backus–Naur_Form) or
> ‘Bison’
> (http://www.gnu.org/software/bison/manual/html_node/Introduction.html).
You want too much.
The closest thing to a manual is Documentation/kernel-parameters.txt in the
kernel source tree. The only example there uses double quotes.
I suggest you enter a sample input line in the command line place in grub or
grub2 and see what comes out in /proc.
I have got a different opinion.
The closest thing to a manual is Documentation/kernel-parameters.txt in the kernel source tree.
Now I have noticed the limitation “COMMAND_LINE_SIZE”. The value of this preprocessor symbol might eventually result in various configuration challenges.