Ideally, you are right. But messing around with the printk
functionality is risky and could be unpopular in the community,
especially if you are only conserving what really amounts to
a small amount of memory (16,32 or 64K, for printk ring buffer).
> Posix and BSD Auditing events are an example for that. In secure mode
> the
> system must be halted on overflow. a printk replacement will want to
> keep the
> oldest entries and a enterprise event system may want to keep the
> oldest.
So I think what you want is to set a "watch" for certain events and
when those event(s) are written to the buffer (1) trigger some action,
like halting the machine, and (2) save the last n events leading-up to
the trigger-action. You might also want to initiate a crash-dump and
be able to retrieve the pinned events from the dump.
Am I on the right track ? Can you give me some idea which information
you would watch for in the events (facility, severity, event_type,
etc.)?
> And I think a flexible policy will allow everybody to
> be
> happy with your framework. the only way to get it accepted, right?
Its not clear that the sort of requirement you are describing...
...In secure mode the system must be halted on overflow...
is needed by the majority of potential event logging users, so could
what you are asking for be implemented as a kernel module ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/