bug#42047: [PATCH 3/3] guix: gc: Support for the Hurd.

[Bengt Richter <bokr@bokr.com>]

On +2020-06-25 22:48:43 +0200, Ludovic Courtès wrote:
> "Jan (janneke) Nieuwenhuizen" <janneke@gnu.org> skribis:
> 
> > * guix/store/roots.scm (proc-environ-roots): Handle EIO, for the Hurd.
> > * gnu/build/hurd-boot.scm (set-hurd-device-translators): Mount /proc.  Add
> > symlink to /etc/mtab.  Remove duplicate calls to 'scope'.
> 
> Nitpick: I see 3 mostly unrelated patches: (1) fix duplicate called to
> ‘scope’, (2) mount /proc, and (3) handle EIO.  I think it’s clearer to
> view them separately.
> 
> (1) and (2) LGTM!
> 
> > -  (mkdir* (scope "dev/vcs/1"))
> > -  (mkdir* (scope "dev/vcs/2"))
> > -  (mkdir* (scope "dev/vcs/2"))
> 
> Was it creating like /some/root/some/root/dev/vcs/1?
> 
> >    (append-map rhs-file-names
> > -              (split-on-nul
> > -               (call-with-input-file environ
> > -                 get-string-all))))
> > +              (catch 'system-error
> > +                (lambda _
> > +                  (split-on-nul
> > +                   (call-with-input-file environ
> > +                     get-string-all)))
> > +                (lambda args
> > +                  (if (= EIO (system-error-errno args))
> > +                      '()
> > +                      (apply throw args))))))
> 
> This may be papering over a real problem.  Before doing that, I think

I fear paperings-over ;) Would this idea be worth implementing?:

To make sure a "papering over" does not remain un-noticed in an executable,
create a catch-wrapping macro that would generate code acting like catch but
before entering catch, start emitting complaint messages on and
after a calendar date, e.g. checked with (> (car (gettimeofday)) *macro-produced-date-constant*)

E.g., something to use in place of catch, like (borrowing above for example)
              (catch-with-sunset "date-string" "complaint-message"
	        'system-error
		 (lambda _
		   (split-on-nul
		   ...etc...
		   (apply throw args))))

"complaint-message" could obviously contain bug#number, commit id, or plea for report, etc.

(gettimeofday) on my machine is about 50ns (i.e., often get 20 equal values within the microsecond resolution),
so there shouldn't be a performance hit ;)

> “we” :-) should investigate why procfs returns EIO in some cases and
> look into fixing it.
> 
> Then maybe we can still have the ‘catch’ above, but this time as a
> temporary measure and with a reference to the upstream issue/commit.
> 
> WDYT?
> 
> Thank you!
> 
> Ludo’.
> 
> 
> 

-- 
Regards,
Bengt Richter