Page MenuHomeFreeBSD

newvers: Add comment about why we need sccs, but deprecate it
ClosedPublic

Authored by imp on Sep 26 2023, 3:45 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 8, 4:10 PM
Unknown Object (File)
Fri, Nov 8, 2:40 PM
Unknown Object (File)
Fri, Nov 8, 12:56 PM
Unknown Object (File)
Oct 14 2024, 7:03 AM
Unknown Object (File)
Oct 2 2024, 4:42 AM
Unknown Object (File)
Sep 14 2024, 9:48 PM
Unknown Object (File)
Sep 4 2024, 8:15 AM
Unknown Object (File)
Aug 19 2024, 9:29 PM

Details

Summary

The SCCS ID is still the most reliable way to dig out the version
information from the kernel w/o false positives. Add a comment to that
effect. savecore(8) neglects to save the kerneldumpheader that would
have the version information at a fixed location. savecore(8) needs to
be augmented to have the right data in the right places, but until then
the old-school SCCS id needs to remain. Once that's fixed, we plan to
remove it.

The reason it needs to be in a fixed or easily findable location is
because if you have an arbitrary core and want to pull the source and
build artificts that went along with that core, you don't yet have the
symbols you need to read the version string. To solve the chicken / egg
problem, one needs an independent way to know what to use so that
automated analysis of cores can happen. The sccs id being in the kernel
ensures that it is in the core image written.

Sponsored by: Netflix

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

imp requested review of this revision.Sep 26 2023, 3:45 PM
imp created this revision.
This revision is now accepted and ready to land.Sep 26 2023, 4:09 PM
sys/conf/newvers.sh
315

I'm not sure that the "used by scripting" matches the "Despite" -- sccs implies that this should relate to ancient history

This revision now requires review to proceed.Sep 26 2023, 5:50 PM
sys/conf/newvers.sh
315

redid completely. I couldn't see ho to fix the old stuff. This is a tiny bit more verbose, but maybe is better.

This revision is now accepted and ready to land.Sep 26 2023, 6:37 PM

"used to marker" seems odd but message overall lgtm

FWIW Juniper depend on what(1) strings in kernels, libs and applications (we use contrib/bmake/mk/whats.mk or similar) to automate the finding of the build trees to match core files and crash dumps.

rpokala added inline comments.
sys/conf/newvers.sh
315

fix wording from ropkala, emaste. Add details about what(1) and soften the
deadline since multiple organizations are using this.

This revision now requires review to proceed.Sep 26 2023, 8:33 PM
imp marked 2 inline comments as done.Sep 26 2023, 8:40 PM
netchild added inline comments.
sys/conf/newvers.sh
318

Would it be beneficial to mention what those better methods (which seem to exist already based on the wording) are?

319

s/removed a/removed in a/

imp marked 2 inline comments as done.Sep 27 2023, 4:12 PM
imp added inline comments.
sys/conf/newvers.sh
318

no. That's an even longer digression since it involves switching to elf format, build-id or other arbitrary markers in the file that are saved as notes in the vmcore file. Today's vmcore files are not ELF and this would either result in a cryptic comment or something that's too long and rambling.

obrien added inline comments.
sys/conf/newvers.sh
318

What are these better methods that one can switch to today?
They should be added to what.1

This revision was not accepted when it landed; it landed in state Needs Review.Sep 27 2023, 11:12 PM
This revision was automatically updated to reflect the committed changes.
imp marked an inline comment as done.