unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel@gnu.org
Subject: Re: [V2 PATCH 1/1] services: Add agetty service.
Date: Fri, 17 Feb 2017 09:24:24 -0500	[thread overview]
Message-ID: <20170217142424.GA6165@jasmine> (raw)
In-Reply-To: <87tw7t8dgz.fsf@elephly.net>

[-- Attachment #1: Type: text/plain, Size: 3205 bytes --]

On Fri, Feb 17, 2017 at 08:48:28AM +0100, Ricardo Wurmus wrote:
> Leo Famulari <leo@famulari.name> writes:
> > Is this the right way? Or would we rather wrap only the most
> > commonly-used options, and leave an "escape hatch" as in the first
> > version of the patch? If so, which options should we expose in Scheme?
> 
> That’s hard to say.  I like to *always* keep an escape hatch, which is
> useful in case we are too slow to adapt our code to changes introduced
> by new versions.  In my opinion this version of the patch is better
> because it exposes more values; it would be even better if it added a
> general purpose escape hatch.

Okay.

> Okay.  (Can we generate documentation for the individual fields somehow?)

Well, I'd really like that! IMO, the service that exposes most of
agetty's options can be fully understood by reading the agetty(8) man
page. I don't look forward to paraphrasing agetty(8).

> Some naive comments follow.

It's okay, my implementation is a naive copy-and-extend of the mingetty
service :)

[...]

> > +                          #$@(if remote?
> > +                                 #~("--remote")
> > +                                 #~())
> 
> Looking at all the syntactic noise makes me long for some prettier
> abstraction here, but I can’t think of anything that would make this
> considerably prettier.  Oh well… ¯\_(ツ)_/¯

Agreed but, on the other hand, this is the level of abstraction that I
understand. So, maybe that's a good thing for other Scheme newbies.

> Maybe add a FIXME here, so we can more easily find it.  It might also be
> worth opening a bug report after merging this, so that we can track it.

Okay.

> 
> > +                          #$@(if no-newline?
> > +                                 #~("--nonewline")
> > +                                 #~())
> 
> I’m sure this will trip me up in the future.  “nonewline” vs
> “no-newline” – I prefer your choice, but the double negative is tough
> for me…

I tried to copy the upstream configuration options but make them
"Scheme-y" stylistically.

> > +                          #$@(if no-hostname?
> > +                                 #~("--nohostname")
> > +                                 #~())
> > +                          #$@(if long-hostname?
> > +                                 #~("--long-hostname")
> > +                                 #~())
> 
> Should we try to prevent nonsensical combinations of options?
> Would it just be more confusing to merge “no-hostname?” and “long-hostname?” as
> “print-hostname 'none 'long 'short”?

Sure... volunteers welcome :) 

It was suggested in the past to reimplement mingetty in Scheme (it's
~400 lines of C). That's a case where we can really understand and
control how the program is used. But for this case, we'd need an agetty
expert.

We could also add an activation phase that creates device nodes beyond
ttyS0, because only ttyS0 is created on GuixSD currently. Either that or
limit this service to ttyS0, instead of leaving the choice to the user.
That's something that I will try to do.

Thanks for your review!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-02-17 14:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15  0:12 [PATCH 1/1] services: Add agetty service Leo Famulari
2017-02-15  0:24 ` Leo Famulari
2017-02-15 15:21   ` myglc2
2017-02-15 19:38   ` Leo Famulari
2017-02-16  7:06   ` [V2 PATCH " Leo Famulari
2017-02-17  7:48     ` Ricardo Wurmus
2017-02-17 14:24       ` Leo Famulari [this message]
2017-02-17 18:35     ` myglc2
2017-02-17 22:59       ` Leo Famulari
2017-02-18  1:23         ` myglc2
2017-03-07 14:43         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170217142424.GA6165@jasmine \
    --to=leo@famulari.name \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).