From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: [V2 PATCH 1/1] services: Add agetty service. Date: Fri, 17 Feb 2017 13:35:44 -0500 Message-ID: <86poig3bsv.fsf@gmail.com> References: <8b9a83141665a7a86aa3d3c9ba6363c1ba2e93cd.1487117562.git.leo@famulari.name> <20170215002417.GA19546@jasmine> <20170216070650.GA21674@jasmine> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cenNn-000605-77 for guix-devel@gnu.org; Fri, 17 Feb 2017 13:35:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cenNk-0003ww-4S for guix-devel@gnu.org; Fri, 17 Feb 2017 13:35:51 -0500 Received: from mail-qk0-x244.google.com ([2607:f8b0:400d:c09::244]:35509) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cenNk-0003wN-0o for guix-devel@gnu.org; Fri, 17 Feb 2017 13:35:48 -0500 Received: by mail-qk0-x244.google.com with SMTP id u25so7709931qki.2 for ; Fri, 17 Feb 2017 10:35:47 -0800 (PST) In-Reply-To: <20170216070650.GA21674@jasmine> (Leo Famulari's message of "Thu, 16 Feb 2017 02:06:50 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Leo Famulari Cc: guix-devel@gnu.org On 02/16/2017 at 02:06 Leo Famulari writes: > On Tue, Feb 14, 2017 at 07:24:17PM -0500, Leo Famulari wrote: >> This 'extra' is a time-saving kludge. I'll add fields for all of >> agetty's configuration options once I'm satisfied that the service works >> on GuixSD. > > Here's a patch that exposes (almost all) of agetty's command-line > options. > > 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? > > I'll wait for feedback before writing the documentation. Hi Leo, I think that what you have is great. With this in my system config ... (agetty-service (agetty-configuration (tty "ttyS1") (baud-rate "115200"))) ... it works painlessly on a headless GuixSD server over IPMI. I think you can put a brief example in the doc, refer the user to the code and the agetty man page for more info, and declare victory. But let me digress a bit on this topic. What if, in situations like this, Guix provided an easy way to export the "native config" generated by Guix? Then we could tell the user ... 1) If you want to know exactly what we are doing, export the native config and read the native doc. 2) If you want features we don't support, export the native config, read the doc, modify it, and feed it into the "native config hatch." With this approach, we could implement and document only "key features" with a clear conscience. When we haven't implemented a feature the user needs they will be no worse off that they were before. In fact, they will usually be ahead, because Guix has taken care of the general requirements and provided a sound starting point for a native config.