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

[Jacob Moody <moody@mail.posixcafe.org>]

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