[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42047: [PATCH 3/3] guix: gc: Support for the Hurd.
From: |
Bengt Richter |
Subject: |
bug#42047: [PATCH 3/3] guix: gc: Support for the Hurd. |
Date: |
Fri, 26 Jun 2020 00:25:04 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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