Right now, we're opening /dev/kmsg through the filesystem. Ideally, we'd do this without such external dependency. Unfortunately, there doesn't appear to be a way to open a character device using major/minor numbers via the kernel's exported symbols. However, LKRG has hackish kernel symbol lookup anyway, and if we don't mind plugging the net code into LKRG more deeply, we can reuse that existing hack to look up devkmsg_open or kmsg_fops and then call devkmsg_open directly.
Presumably, this could make a difference for some setups that load LKRG e.g. from initrd, although quite possibly those do have /dev/kmsg in there anyway? Network is likely to be down at that time, but LKRG would connect when it's up and send whatever relevant messages were buffered.
As an alternative, we could be repeating attempts to open /dev/kmsg much like we attempt reconnects, except that once an attempt succeeds we don't need to be attempting any further (can't get "disconnected" from /dev/kmsg), so we would also not be susceptible to risks of this device file being substituted later (possibly maliciously).
Nov 28, 2022
An alternative is to read using kmsg_dump_get_line, which is an exported symbol, but that function's prototype differs across our supported kernels and there doesn't appear to be an exact equivalent of SEEK_END and also that function does not reach info_print_ext_header and so does not provide all of those extra fields unconditionally. There is kmsg_dump_rewind, but it considers clear_seq, so would be affected by "clearing" of the buffer from userspace.
Nov 10, 2022
Right now, we're opening
/dev/kmsgthrough the filesystem. Ideally, we'd do this without such external dependency. Unfortunately, there doesn't appear to be a way to open a character device using major/minor numbers via the kernel's exported symbols. However, LKRG has hackish kernel symbol lookup anyway, and if we don't mind plugging thenetcode into LKRG more deeply, we can reuse that existing hack to look updevkmsg_openorkmsg_fopsand then calldevkmsg_opendirectly.Presumably, this could make a difference for some setups that load LKRG e.g. from
initrd, although quite possibly those do have/dev/kmsgin there anyway? Network is likely to be down at that time, but LKRG would connect when it's up and send whatever relevant messages were buffered.As an alternative, we could be repeating attempts to open
/dev/kmsgmuch like we attempt reconnects, except that once an attempt succeeds we don't need to be attempting any further (can't get "disconnected" from/dev/kmsg), so we would also not be susceptible to risks of this device file being substituted later (possibly maliciously).Nov 28, 2022
An alternative is to read using
kmsg_dump_get_line, which is an exported symbol, but that function's prototype differs across our supported kernels and there doesn't appear to be an exact equivalent ofSEEK_ENDand also that function does not reachinfo_print_ext_headerand so does not provide all of those extra fields unconditionally. There iskmsg_dump_rewind, but it considersclear_seq, so would be affected by "clearing" of the buffer from userspace.