From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 21 20:42:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56272C8F; Thu, 21 Aug 2014 20:42:39 +0000 (UTC) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3967354F; Thu, 21 Aug 2014 20:42:38 +0000 (UTC) Received: from fwd02.aul.t-online.de (fwd02.aul.t-online.de [172.20.26.148]) by mailout06.t-online.de (Postfix) with SMTP id A381515C876; Thu, 21 Aug 2014 22:42:36 +0200 (CEST) Received: from [192.168.119.26] (Z2Yi8+ZFohyBu3zAsvyp4erIYQOfn6AN73iHZd6W3kHaFgJ6pjivkGgkXiRvV5lwNc@[84.154.101.219]) by fwd02.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XKZBq-24QfD60; Thu, 21 Aug 2014 22:42:34 +0200 Message-ID: <53F659B0.1010602@freebsd.org> Date: Thu, 21 Aug 2014 22:42:24 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Aleksandr Rybalko Subject: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons References: <53F30A81.9090302@freebsd.org> <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> In-Reply-To: <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> Content-Type: multipart/mixed; boundary="------------050408030606020803030900" X-ID: Z2Yi8+ZFohyBu3zAsvyp4erIYQOfn6AN73iHZd6W3kHaFgJ6pjivkGgkXiRvV5lwNc X-TOI-MSGID: 9372b3d9-bddd-49d1-96e2-b7cd658be5b2 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 20:42:39 -0000 This is a multi-part message in MIME format. --------------050408030606020803030900 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Am 21.08.2014 um 10:09 schrieb Aleksandr Rybalko: > Hello Stefan! > > There is my opinion. hi Aleksandr, thank you for taking the time to comment on my long list of questions! > On Tue, 19 Aug 2014 10:27:45 +0200 > Stefan Esser wrote: > >> As you all probably know, 10.1 will ship with both SYSCONS and NEWCONS. >> >> I'm working keymap files for NEWCONS (translated from those in SYSCONS), >> and they'll need to be named differently than before. >> >> The SYSCONF keymap names in rc.conf will not work for NEWCONS. They >> include an encoding scheme in their name, while NEWCONS universally >> uses Unicode. >> >> There are a few points that still need to be considered for 10.1: >> >> a) Is rc.d/syscons still an appropriate name when using NEWCONS? >> (I'd leave it unchanged, but I thought I'd ask ...) > > It should follow same rules as other parts. So if we support > syscons(4) kernel config options for compatibility, we should make it > compatible too. (Then remove it all with syscons(4) removal) I'm not sure that I fully understand your reply. Since vt has been made compatible with syscons to a certain degree, vt can still be configured with the rc.d file originally developed for syscons. We could make rc.d/syscons just exit if a system uses vt, and have a rc.d/vt (initially copied from rc.d/syscons, will probably diverge over time). Of course, rc.d/vt will also just exit on a system using syscons. But I think there are good reasons to have just one startup file with a generic name, e.g. rc.d/console (only in -CURRENT, keeping the file name in 10 as is seems to be wise). >> b) Do we need to identify NEWCONS vs. SYSCONS in the messages printed >> by that rc script? (I guess this might be a good idea.) > > vt(4) print information about its attachment, so no requirement to do > same once again. But will be nice to warn user on use syscons(4) rc > variables with vt(4). I agree, that the vt(4) attach message should be sufficient. >> c) Do we expect to warn the user when he has a SYSCONS keymap name >> specified in the rc.conf "keymap" variable, while using NEWCONS? >> (This might be a good idea, at least when the default is to use >> NEWCONS and the user might not be aware of the change.) > > Yes. User have to know - "something can work incorrect". > But I think with your great work on keymaps translation it will not > have a place. :) Well, if a system is upgraded from 9 to another release that defaults to vt (or even has syscons removed), then the keymap will not be found under its old name. There probably will a suitable keymap for use with vt, and that leads to questions d) and e). >> d) Do we want to provide the user with an information regarding the >> name of the SYSCONS keymap configured, to ease the transition? >> (Could be done ...) > > IMO - yes I guess we could have a conversion map from SYSCONS keymap files to NEWCONS files. The names of the SYSCONS keymaps are static and thus can just be embedded in a map command, which I'll propose shortly. This can be an optional part of the common startup file (i.e. a modification to rc.d/syscons, that is only invoked for systems that use vt), or it could be the first change to a copy of rc.d/syscons to rc.d/vt ... >> e) Do we want the rc script to translate the SYSCONS keymap name >> to its new form? (This might be good for people using foreign >> keyboards, if their password uses characters located at other >> positions than on the default keymap, that will be used if no >> valid "keymap" is specified.) With the approach described above (lookup of the vt keymap name based on the syscons name, in case the keymap cannot be found in vt/keymaps), it is easy to just activate the correct keyboard. The user should probably get rc.conf fixed, before this convenience code is removed, some time (one release?) after a release that has SYSCONS removed. >> f) It might be good to introduce "keymap_sc" (and/or "keymap_vt") >> as a value used in preference to "keymap" if defined and the >> corresponding console driver is detected. (An alternativ to >> e) that is easier to implement and still allows to have one >> rc.conf file that covers both SYSCONS and NEWCONS.) > > IMO good idea to name default one as 'keymap' + both version with > suffixes. With the mapping approach described above (either a sed command, or a shell case statement, but I'd prefer to use sed), this will not be necessary. All keymap file names are either unchanged (e.g. us.emacs.kbd) or exist only in one directory. In the latter case, it is easy to derive a vt keymap name from the syscons keymap name. The opposite could be possible, if a locale has been selected and the encoding to use can be derived from it. But I do not think that a mapping to SYSCONS names will be of much use. If you just want to try vt, you'll be glad to see that a matching NEWCONS keyboard is found, even though you still have the SYSCONS keymap configured. Once you edit rc.conf, you'll probably not want to go back to SYSCONS ... I have attached a shell script containing the sed commands that is able to translate all file names in syscons/keymaps to the names used for vt. The sed commands from this files could be imported into rc.d/vt (as copied from rc.d/syscons), or it could be imported into rc.d/syscons (if that script is meant to support both syscons and vt). What do you think about this approach? Best regards, STefan --------------050408030606020803030900 Content-Type: text/plain; charset=windows-1252; name="conv-name.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="conv-name.sh" #!/bin/sh keymap=$1; shift SC_DIR=/usr/share/syscons/keymaps VT_DIR=/usr/share/vt/keymaps keymap=`basename "$keymap" .kbd`.kbd if [ -r $VT_DIR/$keymap ] then echo $keymap exists in vt/keymaps else if [ -r $SC_DIR/$keymap ] then keymap=$(echo $keymap | sed -e " s/\.koi8-[ur]\././ s/\.106\././ s/\.us101\./.101./ s/\.ctrlcaps\././ s/\.106x\./.capsctrl./ s/\.pc-ctrl\./.ctrl./ s/\.cp850-ctrl\./.capsctrl./ s/\.iso-ctrl\./.capsctrl./ s/\.iso[0-9]*\././ s/\.q\././ s/\.latin[0-9]\././ s/\hy\.armscii-8\./am./ s/\.ISO8859-[0-9]*\././ s/\.pt154\././ s/\.\([1-9][0-9]*\)keys\./.\1./ s/\.101keys\./.101./ s/\.macbook\.acc\./.macbook./ s/\.cp[0-9][0-9]*\././ s/^eee_nordic\./nordic.asus-eee./ s/^spanish\./es./ s/^norwegian\./es./ s/^belgian\./be./ s/^swissgerman\./ch./ s/^swissfrench\./ch-fr./ s/^ch\.macbook\./ch.macbook.acc./ s/^fr_CA\.acc\./ca-fr./ s/^br275\.acc\./br./ s/^br275\./br.noacc./ s/^colemac\.acc\./colemac./ s/^estonian\./ee./ s/^swedish\./se./ s/^finnish\./fi./ s/^danish\./dk./ s/^dutch\.acc\./nl./ s/^icelandic\./is./ s/^german\./de./ s/^pl_PL\./pl./ s/^el\./gr./ s/^iw\./il./ s/^kk\./kz./ s/^cs\.qwertz\./cz./ s/^ce\./centraleuropean./ ") if [ -r $VT_DIR/$keymap ] then echo "$keymap exists in vt/keymaps (after conversion)" else echo "$keymap not found (after conversion)" fi else echo "$keymap is not a valid syscons keymap" fi fi --------------050408030606020803030900--