James C. McPherson wrote:
Darren J Moffat wrote:
Stephen Lau wrote:
Just to poke this thread some more, the overwhelming consensus I've
seen has been to:
- Stop using keywords for module versions
I'd like to just eliminate the use of keywords entirely, if this is
the case. There doesn't seem to be a use for them, other than the
misleading use of modinfo to determine a driver version. And it's
been sufficiently pointed out in this thread that that is a poor
decision given the other better alternatives.
Does anyone see a problem with dropping keywords in their entirety?
No problem at all in fact quite the opposite it is a good thing to
drop keywords they only confuse people in to thinking they have
information that they really don't have.
I also talked to some Sun field engineers who initally said that we
should keep this, I think explained all the caveats that were
discussed here and they instantly changed their mind to drop keywords.
I also had misgivings about dropping keywords, but then I stood
back for a few minutes and thought about it.
We've got a unique hash which identifies "binary X". We can create
a publishable mapping (ie, on sunsolve) between that hash and the
version of the source that it is based on.
Why is it needed that you map a given random binary to source files ?
The wsdiff tool may help here though.
Sun already has the finger print database which maps the binaries going
back all the way to Solaris 2.0 and patches to MD5 hashes.
The various automagical tools that Support Services people make
use of can definitely be re-targeted to make use of said hash(es).
My remaining concern is/was secure sites, where Sun has to send
an SSE onsite to do things. Reading a unique hash over the phone
line is going to be a pain in the rear (and yes, it will happen),
but I think the benefits of the hash will outweigh the downsides.
It isn't that hard, plus even on secure sites like that you should be
able to get the hashes off site after all they are public information
after all!
--
Darren J Moffat
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
