#1180 closed enhancement (fixed)
SVN source revision in serial output (easy)
| Reported by: | jonas.kirilla | Owned by: | bonefish |
|---|---|---|---|
| Priority: | low | Milestone: | R1 |
| Component: | System/Kernel | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Wouldn't it be nice if the source code revision was printed as part of the serial output? I suppose as close to the start as possible, or right after "Welcome to kernel debugger output!", if that makes sense.
This way, any serial output that gets posted online, uncut, can be pin-pointed to a revision, and a source of information beyond the reason it was posted.
Change History (6)
comment:1 by , 17 years ago
| Priority: | normal → low |
|---|---|
| Summary: | SVN source revision in serial output → SVN source revision in serial output (easy) |
follow-up: 4 comment:2 by , 17 years ago
comment:3 by , 17 years ago
I think that all libroot functions are available in the kernel, so you should be able to simply call uname() and do the same as AboutHaiku. Or am I missing something?
comment:4 by , 17 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
Replying to jonas.kirilla:
Would 'set_haiku_revision' and a similar uint32 sHaikuRevision work for the kernel? Is it desirable to do it this way?
Yep.
What if a private revision.h file was created early in the build process and this was used instead? Would that trigger a lot of recompiling even if it was only referenced in the few places where it might be needed?
It wouldn't trigger much recompiling, but a lot of relinking. In case of the kernel, every kernel add-on (module, driver) would be linked again. In case of libroot every userland program would be relinked. Which is exactly the reason why it is done using the injection trick.
Replying to wkornewald:
I think that all libroot functions are available in the kernel, so you should be able to simply call uname() and do the same as AboutHaiku. Or am I missing something?
Only the libroot code that is explicitely included in the kernel (cf. src/system/kernel/lib/Jamfile) is available. uname() isn't ATM. And just doing that wouldn't help either, since the mechanism injecting the revision number is performed right before copying the file to the image.
Anyway, I'm going to add the revision number to the kernel.
There doesn't appear to be a trivial way to inject the current SVN revision of the entire tree. The five available svn substitution keywords are file-oriented rather than tree-oriented.
AboutHaiku gets its revision info from libroot's uname().
Libroot gets its revision info from the following in src/system/libroot/posix/sys/uname.c
" Haiku SVN revision. Will be set when copying libroot.so to the image. Lives in a separate section so that it can easily be found. static uint32 sHaikuRevision attribute((section("_haiku_revision"))); static uint32 sHaikuRevision = 0; "
When libroot gets built, the value of sHaikuRevision is 0, and the revision is added, I believe, as stated when copying libroot.so to the build target, by build tool 'set_haiku_revision', which gets called by jam rule CopySetHaikuRevision used in libroot's Jamfile. The rule gets the revision by parsing the output of 'svn info'. This info is then injected by set_haiku_revision into libroot.so.
Would 'set_haiku_revision' and a similar uint32 sHaikuRevision work for the kernel? Is it desirable to do it this way?
What if a private revision.h file was created early in the build process and this was used instead? Would that trigger a lot of recompiling even if it was only referenced in the few places where it might be needed?
haiku/src/system/boot/loader/main.cpp :: line 46 "Welcome to kernel debugger output!"
That's where I think a "Haiku revision: ???" should follow.