Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: P5music on January 01, 2011, 12:36:41 PM
-
Hi,
I need to know which script or executable generates the output that can be seen if "quiet" boot option is not present in syslinux.cfg, before the rcS output itself.
Please answer if you know this information.
Thanks in advance
-
What makes you think a script or executable would generate output?
The kernel itself is reporting events by default.
-
taking in account the optimized nature of tinycore, is this output generated from a single main init function (or similar) in order to log what it's encountering, or instead from many modules / procedures?
-
Not in a position to speak on behalf of the devs, but generally speaking, I couldn't think of any known way how optimization could influence basic kernel messages.
What differs with TC is that the syslog daemon would only be started at boot time if explicitely stated as a boot parameter.
-
@P5music: I'm reasonably confident to state that the execution of '/init' or /sbin/init' are not producing any messages on the screen. In my answer (http://forum.tinycorelinux.net/index.php?topic=7825.msg41922#msg41922) to one of your earlier questions I had attempted to describe the boot process. This is by and large similar for other distributions as well. Only that those are typically using an initrd to "prepare the ground" for switching over to their root file system.
So, in summary: The kernel itself will by default produce messages during the boot process. Those can be supressed with the boot code 'quiet' (which is the default for the TC ISO). This suppression can again be over-written with the 'debug' boot code, which could be specified at the ISOLINUX 'boot:' prompt. Those kernel messages should be available via the 'dmesg' command' or stored in '/var/log/messages' when the 'syslog' boot code is used.
There is to the best of my knowledge no other "message producing entity" prior to the execution of '/etc/init.d/rcS' (or rather '/etc/init.d/tc-config'). The first TC specific output is generated by the 'clear' command followed by the "Booting tinycore_3.4.1" message (or something similar) from '/etc/init.d/tc-config'. All subsequent messages are produced either by this script or any other called by it (e.g. '/usr/bin/tce-setup'). None of the TC specific screen output is captured by 'dmesg' (or in '/var/log/messages'), but one could use the 'pause' boot code to take a moment and admire what "tce-config and friends" have written to the screen.
-
No doubt, but I don't think that conflicts with my statement - at least not when interpreting "taking in account the optimized nature of tinycore" (to quote OP) as optimization for resources usage and speed.
-
thank you all!
I used the dmesg command so I could examine syslog output.
Now I ask you :
1) if it is possible to get this log with timestamps for each occurrence.
2) where could I find documentation/advice about what yelds each occurrence, that is: exactly which kernel function performs the operation each occurrence refers to.
-
thank you friend,
your explanation was so much clear.
I think I could also edit the source of printk function itself for it to add timestamp every time it is called, couldn't?
Is it right? If yes, where is it?
Furthermore, is it possible for it to know which function has called it? Maybe this is not possible.
-
The bootcode "printk.time=1" adds timestamps to the kernel messages.
-
2) where could I find documentation/advice about what yelds each occurrence, that is: exactly which kernel function performs the operation each occurrence refers to.
http://kernelnewbies.org/
Some interesting article is here, more than 10 years old though, but still very informative:
http://linuxgazette.net/issue59/nazario.html
-
I found this:
#define WHERE printf("We are in %s", __func__)
void Function(void) {
WHERE;
}
it could be useful if one wanted to edit all the printk occurrences...
Or maybe there's a macro or a runtime function useful to find the name of the caller function so to edit the kernel/printk.c source file putting this information in the printk output?