12:47 p.m.
Hi Dave,
Sorry about the delay. I've finally found the time to attempt another version.
As per your request, I've updated *help_mod[] to document the -T option.
Also in this particular version, I omit ' ' and '-', when false, as
I'm under
the impression that we're only interested in true values as per module_flags()
(since 2.6.25).
I suspect that there shouldn't be a situation where a module isn't tainted since
every module is either proprietary license or GPL. However, if this is not
acceptable I can change this behaviour.
For module.gpgsig_ok case (as seen in kernel-2.6.32-1.el6), I've decided to follow
the same logic to highlight "(U)" to the user, as per print_modules().
With regards to module.sig_ok, this is handled, as seen under 3.8.9-200.fc18:
nf_nat G
bnx2i G
ip6t_REJECT G
nf_defrag_ipv6 G
be2iscsi G
tun G
test GFO
For pre 2.6.28 kernels, I'll work on a solution that simply displays the bit number
to then refer the user to the relevant kernel source for details on what the bit
number means, as per your suggestion. I just wanted to get this version out to the
mailing list for review.
Cheers,
Aaron
--8<--
help.c | 18 ++++++++-
kernel.c | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 140 insertions(+), 2 deletion
2:07 p.m.
----- Original Message -----
Hi Dave,
Sorry about the delay. I've finally found the time to attempt another
version.
As per your request, I've updated *help_mod[] to document the -T option.
Also in this particular version, I omit ' ' and '-', when false, as
I'm under
the impression that we're only interested in true values as per module_flags()
(since 2.6.25).
I suspect that there shouldn't be a situation where a module isn't tainted since
every module is either proprietary license or GPL. However, if this is not
acceptable I can change this behaviour.
For module.gpgsig_ok case (as seen in kernel-2.6.32-1.el6), I've decided to follow
the same logic to highlight "(U)" to the user, as per print_modules().
With regards to module.sig_ok, this is handled, as seen under 3.8.9-200.fc18:
nf_nat G
bnx2i G
ip6t_REJECT G
nf_defrag_ipv6 G
be2iscsi G
tun G
test GFO
For pre 2.6.28 kernels, I'll work on a solution that simply displays the bit number
to then refer the user to the relevant kernel source for details on what the bit
number means, as per your suggestion. I just wanted to get this version out to the
mailing list for review.
Right -- it seems reasonable to at least print a hexadecimal value for the
earlier kernels. The "help mod" output should state something to the effect
that
the relevant kernel sources should be consulted for the meaning of either the
letter(s) or hexadecimal bit-value(s).
Also, this piece had me scratching my head a little bit:
if (is_module_taint(lm, buf2, &maxtnts_len)) {
fprintf(fp, "%s ", mkstring(buf1, maxnamelen,
LJUST, lm->mod_name));
fprintf(fp, "%s\n", mkstring(buf2, maxtnts_len,
LJUST, buf2));
}
Why bother with the "maxtnts_len" business and the mkstring() call for the
taints string? I understand that the lm->mod_name should be passed to
mkstring() to keep that field length common (i.e. maxnamelen), but for
the taint string, you can just print it as-is without bothering to do
any kind of justification or worrying about the field length. Since the
string is left-justified when created, and since it's got nothing to
display after it, you can just do this:
fprintf(fp, "%s %s", mkstring(buf1, maxnamelen,
LJUST, lm->mod_name), buf2);
I'm guessing that it's just a left-over from your earlier patch where
you were squeezing it in the general "mod" display string...
Thanks,
Dave
Cheers,
Aaron
--8<--
help.c | 18 ++++++++-
kernel.c | 124
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 140 insertions(+), 2 deletion
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
4221
days inactive
4221
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Aaron Tomlin -
Dave Anderson