> That said, I am playing with it and it is looking promissing. I liked
> Borislav idea of having an always-present array and use your error
> sources to index the array.
>
> > static struct recovered_error_info {
> > int num_recovered_errors;
> > time64_t last_recovered_error_timestamp;
> > } recovered_error_info[ERR_NUM_SOURCES];
>
> I know naming is hard. Playing with it, I thought about the
> hwerror_tracking as the "name" for this feature. Does it sound ok?
Much better than the name I picked. But easy to swap out if
somebody suggests something better.
> > void log_recovered_error(enum recovered_error_sources src)
> > {
> > recovered_error_info[src].num_recovered_errors++;
> > recovered_error_info[src].last_recovered_error_timestamp =
> > ktime_get_real_seconds();
> > }
> > EXPORT_SYMBOL_GPL(log_recovered_error);
>
> Where do you think this code should be? I suppose we have a few options:
>
> 1) Maybe a driver called hwerror_tracking in drivers/ directory
> - Pro: Code is self-contained
> - Cons: This will require a CONFIG_HWERROR_TRACKING, around. Also
> it will create some inter dependency of drivers.
>
> 2) A hwerror_tracking.c error in kernel/ and have it always enabled
> - Pro: This is always available, and doesn't depend on the CONFIG dance
> - Cons: There is no way to disable it (?)
>
> 3) In some pre-existing file.
If the intent is still to add this information to vmcore (as in
earlier discussions in this thread). Then it could go into
kernel/vmcore_info.c (and be configured with CONFIG_VMCORE_INFO).
Would just need an empty stub in some header file for the
log_recovered_error() function.
-Tony
