On Fri, Apr 18, 2014 at 09:18:01AM -0700, Matthew Ahrens wrote: > On Fri, Apr 18, 2014 at 9:07 AM, Ira Cooper <[email protected]> wrote: > > On Fri, Apr 18, 2014 at 11:57 AM, Matthew Ahrens > > <[email protected]>wrote: > >> On Thu, Apr 17, 2014 at 11:41 PM, Jim Klimov <[email protected]>wrote: > >>> And on a side note, is there an easy way to know what source commits or > >>> bug fixes are present in the running (installed) kernel - perhaps, a > >>> git/mq > >>> history in a standardly provided text file or something like that? If not, > >>> would it make sense to add such a file to the build-product of > >>> illumos-gate? > >> > >> I think it would be great to do something like this, and include it > >> kernel memory so it's part of the crash dump as well. > >> > >> As a practical suggestion, how about we take the first 1MB of "git log", > >> gzip it, and compile it into a kernel variable. Then add a mdb dcmd to > >> ungzip and print it out. I won't have time to implement this in the near > >> term; if others think this would be useful and have time, I'd be happy to > >> mentor / review. > > > > git log --oneline - the actual commit text doesn't matter as much as which > > commits made it. :) > > For illumos-formatted commit messages, "git log --oneline" includes the > entire actual commit text, just in a harder to read format (all lines > smushed into one). I guess it leaves out the date and the author, both of > which are pretty useful.
Why such a heavy-handed approach? Why not just stash the output from `git describe --dirty --tags` into a const global and calling it descriptive enough? As far as mdb is concerned, you could teach the ::status about it. Jeff. -- We have joy, we have fun, we have Linux on a Sun... _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
