Crisson Hu wrote:
> Hi Jim,
>
> I got perception of the version number issue. Surely it would be a
> problem for now and in the future that should be worked out.
>
> >From our side, we just want a mechanism to identify what revision level
> of driver the system has loaded. Is there any solution for that other
> than the version number? We're willing to replace it with another
> mechanism.
>
Loaded in kernel memory, or the filesystem?
On the filesystem, you can look in the elf comment section to find out
about the driver. This section is updated for each new build of ON.
For example:
> what /kernel/drv/bge
/kernel/drv/bge:
SunOS 5.11 snv_93 January 2008
(which is accurate, because I'm still running build 93 on my desktop).
If you're building your own private copy, it contains information about
your workspace instead. For example:
> what ../audio810/obj64/audio810
../audio810/obj64/audio810:
SunOS 5.11 oss-api October 2007
Where "oss-api" is the name of my workspace. (The date is garbage, of
course, but it comes from one of the parent Makefiles.)
If you need versioning information from a live kernel, there are other
approaches available as well. You could generate a much more complete
information string in the Makefiles (I don't encourage this, but it
could work):
E.g, add the following to bge.c:
const char *bge_build_notes = BGE_BUILD_NOTES;
and in the Makefile for bge do (I've not tested this -- its entirely
possible that there are quoting fixes necessary):
BUILD_NOTES :sh="built on `date` by `whoami`"
CFLAGS += -DBGE_BUILD_NOTES="$(BUILD_NOTES)"
Then you can get the build version by doing
echo bge_build_notes/S | mdb -k
Note that I'm not a fan of this approach. I really don't understand why
the bge driver needs extra handling that no other driver does. Does the
bge team often need to deal with folks who update the bge driver
separately from the rest of their build of Solaris?
-- Garrett
> Regards,
> Crisson
> On Mon, 2008-11-24 at 09:20 -0500, James Carlson wrote:
>
>> Gordon Ross writes:
>>
>>> I don't care much about this version number issue, but
>>> I do think respecting some notion of "ownership" is an
>>> important thing. Given that the i-team in Beijing has
>>> requested this and they "own" this driver, I'd suggest
>>> we let them keep it (and "hold our noses":)
>>>
>>> Are you guys OK with letting the i-team have their way?
>>> We can always take out that version string later...
>>>
>> I think it'd be a darned shame for locally-maintained version numbers
>> on a subset of system components to become common enough that it ends
>> up forcing others to do likewise.
>>
>> We discussed the version numbering issue for individual objects (ad
>> nauseum) on the SCM migration list, as Mercurial doesn't have the same
>> source-changing features as other systems, and the rough consensus was
>> that the numbers should be removed, and that numbering is really a
>> release process issue -- "mcs -a" or part of packaging or both -- and
>> not a source issue.
>>
>> What I don't want to see are 'bugs' filed in the future saying that
>> since bge has its own idiosyncratic source-based numbering scheme,
>> some other driver that doesn't have this is 'flawed.' Moreover, I
>> don't want to see RTI advocates burdened with having to search for
>> obscure local 'rules' about source changes for projects that
>> incidentally modify files in one of these special drivers.
>>
>> That's exactly where this road leads.
>>
>> I agree that the project team should own their code, and should do
>> what they think is right, but like it or not, we're actually building
>> both a source code base and a system as a whole, and we all have
>> responsibility for the whole thing. The way in which one project team
>> chooses to do things _will_ have an effect on others.
>>
>> So, yes, they "can" do this. I think they just shouldn't.
>>
>>
_______________________________________________
networking-discuss mailing list
[email protected]
