Passing boot logs to Linux?

[Csókás Bence]

On 2023. 12. 20. 9:29, Dragan Simic wrote:
> On 2023-12-20 08:52, Csókás Bence wrote:
>> On 2023. 12. 20. 8:09, Dragan Simic wrote:
>>> On 2023-12-20 07:49, Csókás Bence wrote:
>>>> I don't think that would be a huge problem, Linux userspace can filter
>>>> ANSI control codes if it wants to. For now, I'd like a byte-for-byte
>>>> copy of the console, as-is, presented to Linux.
>>>
>>> But wouldn't recording the control sequences as-is actually be pretty
>>> much useless?  For example, some user can spend a few minutes
>>> scrolling through the boot menu, which would produce a fair amount of
>>> nearly useless recorded data.
>>>
>>> Moreover, if I'm not wrong, viewing or parsing such as-is data would
>>> actually require replaying the control sequences, to reproduce the
>>> actual console contents as it was recorded, which would be quite
>>> cumbersome.
>>
>> It *is* useless, but most of the times the user won't be scrolling at
>> all anyways, that's why I don't think these few extra bytes would be a
>> problem.
> 
> Quite frankly, when it comes to computing in general, taking the "ah, it 
> probably won't happen" approach isn't the best thing to do.  We should 
> aim toward covering properly even the edge cases, if you agree.

You're absolutely right; however, I did not say "it won't happen", I 
said that Linux userspace can go deal with it if it happens, and if it 
wants to. And that in my opinion, the best course of action for U-Boot 
is to record *everything* (as it does now), and then userspace can 
decide to filter it for eg. ANSI codes. But I think it's best to keep 
the U-Boot code dead simple, and also supply the most data to userspace.


>> That's what I read as well. Is there support for U-boot to write and
>> Linux to read PStores?
> 
> No and yes, but U-Boot can already read pstore.  Please see 
> doc/usage/cmd/pstore.rst for the U-Boot part, and 
> Documentation/admin-guide/pstore-blk.rst for the Linux kernel part.

Irrelevant, as we only want to write out the console log to U-Boot, and 
not the other way around (that's for collecting panic logs, which is 
already implemented).

> Another benefit of using pstore would be no permanently wasted RAM for 
> the recorded console contents.  Also, having the data recorded to a 
> storage device also goes along with providing permanent records.

I'm positively *not gonna save boot logs to disk*, as most embedded 
systems have Flash-based storage media; writing to them on every boot 
would be devastating. Plus, I don't want the console subsystem to depend 
on any file/disk operations/drivers.

Therefore, it will be necessary to permanently keep the logs in-memory, 
regardless of whether we use the PStore format or something else. Unless 
Linux wants to copy it elsewhere (which probably will be memory 
anyways). But maybe we could offer some option in the Linux driver to 
release the logs, along with the associated memory region...

All in all, I'm all for using pre-existing standard interfaces instead 
of inventing something new and custom, but as I see it now, PStore just 
cannot do what we want here. If any of you think otherwise, feel free to 
try to convince me further, or even guide me on how to use PStores.

Here's what I would want:
* writing already supported in U-Boot
* pure in-memory solution
* minimal overhead to the console subsystem