Re: [V2 PATCH 1/1] services: Add agetty service.

[myglc2 <myglc2@gmail.com>]

On 02/17/2017 at 17:59 Leo Famulari writes:

> On Fri, Feb 17, 2017 at 01:35:44PM -0500, myglc2 wrote:
>> 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.
>
> Awesome!
>
> Veering off-topic, I wonder what created that device node /dev/ttyS1? I
> have 32 of them, but (gnu build linux-boot) appears to only create the
> first one:
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/linux-boot.scm#n160

I found the serial line on my server by doing ...

g1@g1 ~$ dmesg | grep tty
[    0.000000] console [tty0] enabled
[    2.192386] 00:07: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

... but linux-boot.scm only specifies ttyS0 ...

 160    ;; Serial line.  
 161    (mknod (scope "dev/ttyS0") 'char-special #o660  
 162           (device-number 4 64))  

... but gnu/packages/linux-libre-4.9-i686.conf has ...

CONFIG_SND_SERIAL_U16550=m

... so maybe the kernel probes for and finds the UART.

>> 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.
>
> An interesting idea! I guess the implementation would vary based on
> services that use a configuration file (like nginx) and those that are
> configured on the command-line (like agetty). But I'm still finding my
> way around services, in general, so I'm not sure.

Agreed. Ideally there would be a strategy and reusable modules that
supports either approach, or a mix. Then maybe this would lighten the
effort required for each service and help regularize these interfaces.