James C. McPherson writes:
> Stephen Lau wrote:
> > Bill Sommerfeld wrote:
> >> Perhaps more problematic: a number of kernel modules embed keywords like
> >> %I% in literal strings which become admin-visible, especially in
> >> "modstat" output.
> >> What do you propose to do about this?
> > I believe the plan is to remove these...
>
> Whoa there, tiger! Where and by whom is this plan being developed?
> It's certainly news to me.
It's news to me, too, but it doesn't seem surprising. I've always
viewed those as a bit grotty as they don't give the real versioning
information.
It's not real because:
- It's just the SID on the one file that has the string compiled
into it for modinfo. Most kernel modules consist of *MULTIPLE*
source files and the one with this string is often the one that
just has the kernel linkage glue, which rarely (if ever) changes.
Thus, you won't necessarily see it updated when something in the
driver changes.
- It bears no relationship to patch ID numbers, releases, or any
other "official" source of information. This means that you need
to have an illuminated manuscript somewhere engraved with the
mappings between SIDs and patches for every single release. We've
likely got better things to do with our time than manual
compilation of data like that.
> There are a heck of a lot of scripts and analysis which Support
> services people depend on that make use of the %I% information.
Really? Where is that text format documented in way that makes it
possible for some automated tool to _depend_ on it?
That smells like a hack to me. The same rules that go for customers
go for these sorts of scripts: if we haven't documented the format in
a way allows you to parse it, and if you haven't negotiated a contract
on the interface to hold the format stable, then your script can't be
supported and almost certainly will break in the future. It's only a
question of "when," not "if."
That could be a bad thing if it's an important script.
In any event, it looks like you've got the attention of the right
audience. The next step is to outline the _specific_ requirements
(not just "we need the SCCS SID buried in the text"), and then make
sure this new system being proposed gives you some suitably stable way
to get at the information you need.
And I hope it's not just groveling through modinfo tea leaves ...
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
tools-discuss mailing list
[email protected]
