[9front] [PATCH] embed git head hash as /dev/head

[9front] [PATCH] embed git head hash as /dev/head

[Jacob Moody]

This embeds the current commit hash for HEAD
in to devcons as /dev/head. Thought this could be
handy, curious to hear what others think.


thanks,
moody

---
diff 13065e16b3c4fba4d9200ed7fec89ee49338f12a uncommitted
--- a//sys/src/9/port/devcons.c
+++ b//sys/src/9/port/devcons.c
@@ -329,11 +329,13 @@
 	Qzero,
 	Qmordor,
 	Qconfig,
+	Qhead,
 };

 enum
 {
 	VLNUMSIZE=	22,
+	HEADSIZE=	41,
 };

 static Dirtab consdir[]={
@@ -360,6 +362,7 @@
 	"zero",		{Qzero},	0,		0444,
 	"config",	{Qconfig},	0,		0444,
 	"mordor",	{Qmordor},	0,		0666,
+	"head",		{Qhead},	HEADSIZE,	0444,
 };

 int
@@ -466,6 +469,7 @@
 	int i, k, id;
 	vlong offset = off;
 	extern char configfile[];
+	extern char headhash[];

 	if(n <= 0)
 		return n;
@@ -623,6 +627,8 @@
 		snprint(tmp, sizeof tmp, "2000");
 		n = readstr((ulong)offset, buf, n, tmp);
 		return n;
+	case Qhead:
+		return readstr((ulong)offset, buf, n, headhash);

 	default:
 		print("consread %#llux\n", c->qid.path);
@@ -787,6 +793,9 @@
 	
 	case Qmordor:
 		error("one does not simply write into mordor");
+		return 0;
+	case Qhead:
+		error(Eperm);
 		return 0;

 	default:
--- a//sys/src/9/port/portmkfile
+++ b//sys/src/9/port/portmkfile
@@ -55,6 +55,11 @@
 		sed -e 's/^[0-9a-f]+ //' -e 's/ ([0-9a-f][0-9a-f])/0x\1,/g'
 	 echo 0,
 	 echo '};'} >> $CONF.c
+	{echo 'uchar headhash[]={'
+	 xd -1x /dist/plan9front/.git/`{awk '{ print $2 }' /dist/plan9front/.git/HEAD} |
+		sed -e 's/^[0-9a-f]+ //' -e 's/ ([0-9a-f][0-9a-f])/0x\1,/g'
+	 echo 0,
+	 echo '};'} >> $CONF.c

 errstr.h:D:	../port/mkerrstr ../port/error.h
 	rc ../port/mkerrstr > errstr.h

Re: [9front] [PATCH] embed git head hash as /dev/head

[ori]

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> This embeds the current commit hash for HEAD
> in to devcons as /dev/head. Thought this could be
> handy, curious to hear what others think.
> 

not a fan.

usually, my kernels have some uncommitted local patches,
and are sometimes built outside of /sys/src

also, it feels overfit to git.

Re: [9front] [PATCH] embed git head hash as /dev/head

[Jacob Moody]

On 6/10/22 08:07, ori@eigenstate.org wrote:
> Quoth Jacob Moody <moody@mail.posixcafe.org>:
>> This embeds the current commit hash for HEAD
>> in to devcons as /dev/head. Thought this could be
>> handy, curious to hear what others think.
>>
> 
> not a fan.

Fair enough, but I did want to talk a bit about what the
use case for this is.

> 
> usually, my kernels have some uncommitted local patches,
> and are sometimes built outside of /sys/src

I am going to go out on a limb here and say that a majority of
users don't have uncommitted local patches to the kernel.
I view this mostly as something that could assist it debugging,
a lot easier to know what code someone has running in their kernel
if you know what the base commit was at least. I've run in to
a number of users that were unaware of needing to update their
kernels. This gives a concrete answer of 'how out of date is the
kernel'. But this is all fluff, just thought it might prove
useful.

> also, it feels overfit to git.


Wasn't aware we shipped with other version control software :P.
Some improvements that could be made to this:

* We could check for a local .git and use that over the one in /dist if found
* We could record the tidiness of the tree, perhaps either through a 'dity' suffix
to the hash and/or just embedding the entire code diff itself.

But I wont invest more time in to this if people don't like the
idea.


Thanks,
moody

Re: [9front] [PATCH] embed git head hash as /dev/head

[mkf9]

Jacob Moody wrote:
> This embeds the current commit hash for HEAD
> in to devcons as /dev/head. Thought this could be
> handy, curious to hear what others think.
> 
> 
> thanks,
> moody

since this device depends on one specific file,
is there any other device that depends on a file somewhere
in order to work?

Re: [9front] [PATCH] embed git head hash as /dev/head

[Jacob Moody]

On 6/10/22 13:01, mkf9 wrote:
> Jacob Moody wrote:
>> This embeds the current commit hash for HEAD
>> in to devcons as /dev/head. Thought this could be
>> handy, curious to hear what others think.
>>
>>
>> thanks,
>> moody
> 
> since this device depends on one specific file,
> is there any other device that depends on a file somewhere
> in order to work?
> 

Kind of, we embed the kernel 'config' at build time in to
/dev/config. So yes it depends on that file, but you could
call that config part of the source code for the kernel.

Re: [9front] [PATCH] embed git head hash as /dev/head

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

> Wasn't aware we shipped with other version control software :P.

It was hg until just a few months ago.  Don't assume it will be git
this time next year.

Also, I am not a fan of /dev/head. I'd prefer to see this as an attribute
of /dev/config, perhaps added to the start of its output:

  term% cat /dev/config
  # kernel version xyzzy
  #
  # pc64 - amd64 pc terminal with local disk
  [...]
  term%

'xyzzy' can be whatever version string is appropriate.

To be clear, I'm talking about having the /dev/config driver synthesize
those first two lines whenever someone does a read on the file.

--lyndon

Re: [9front] [PATCH] embed git head hash as /dev/head

[Jacob Moody]

On 6/14/22 11:32, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
>> Wasn't aware we shipped with other version control software :P.
> 
> It was hg until just a few months ago.  Don't assume it will be git
> this time next year.

Yeah fair point.

> 
> Also, I am not a fan of /dev/head. I'd prefer to see this as an attribute
> of /dev/config, perhaps added to the start of its output:
> 
>   term% cat /dev/config
>   # kernel version xyzzy
>   #
>   # pc64 - amd64 pc terminal with local disk
>   [...]
>   term%
> 
> 'xyzzy' can be whatever version string is appropriate.
> 
> To be clear, I'm talking about having the /dev/config driver synthesize
> those first two lines whenever someone does a read on the file.
> 

If we did want to add it, I think this would be the way to go.
A lot less intrusive if it does/doesn't exist.

But to take a step back, I haven't seen anyone _love_
this idea. My original intent with this was to provide
the revision in the kernel to assist in debugging.
But I am not entirely convinced this would be useful.
We already have KERNDATE, and it's quite easy to just
say 'update your kernel if you haven't in a while'.
If it becomes suspect in a debugging session.

Since the general update flow to me seems to be:
: sysupdate
: @{ cd /sys/src/ && mk install }

What might be more useful is keeping track of where we
updated from. To have a list of commits as suspect for
if a bug appears after updating. You have this to some extent
already, if you update and things break today, you have a dump
from yesterday with your previous commit hash in /dist/plan9front.
That works fine, but does assume daily dumps. To avoid that assumption
you could have something like /dist/plan9front/revisions or /sys/log/revisions,
append only files that just log the jumps between versions done by sysupdate.
But I dont love this either.

Thanks,
moody