Re: [RFC PATCH 0/6] CCIX rasdaemon support

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Sat, 15 Jun 2019 01:55:11 +0800
Jonathan Cameron <Jonathan.Cameron@huawei.com> escreveu:

> This is an RFC because the kernel side is currently under review and
> may change with obvious follow through effects on this.
> 
> https://lore.kernel.org/linux-edac/20190606123654.78973-1-Jonathan.Cameron@huawei.com/

Yeah, we should wait for it to be merged upstream before adding them to
rasdaemon ;-)

> 
> There are a few additional questions around this:
> 1. Divide between specifity of DB fields vs blobs.
>    Where possible I have tried to fully describe the contents via
>    separate fields rather than large blobs.

OK!

>    One common SQL convention
>    that doesn't seem to have been previously done in rasdaemon is to
>    use explicit NULL entries for elements where data is missing.

We tried to be a simple as possible when we added the dB option.

We even opted to use sqllite, instead of having support for 
MySQL or Postgres - Not only due to simplicity, but also because,
if a machine has problems, a database at the same machine may crash.

That's said, with MySQL/Postgres support, the logs could be done
via a remote machine, with would be safer.

-

I don't see much problem on adding such things to new tables or even
add optional support for other dB types, but Changing the existing dBs 
can be a problem.

Perhaps it could have a table somewhere storing the Rasdaemon version,
in order to be able to detect if a table has missing something. If
Rasdaemon version is bigger than the one at the server, it could do some
database changes in order to support new features - including things like
replacing empty fields by NULL.

If you think such changes would be useful, feel free to submit patches.

> 2. Should we split ras-record.c and have the ccix handling in a separate
>    ras-record-ccix.c file or similar as that one is getting rather large.

Makes sense to me. As all projects, it started small. As things are
getting bigger, it makes sense to split some features on separate
files.

Thanks,
Mauro