Date: Thu, 21 Aug 2014 22:42:24 +0200 From: Stefan Esser <se@freebsd.org> To: Aleksandr Rybalko <ray@ddteam.net> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons Message-ID: <53F659B0.1010602@freebsd.org> In-Reply-To: <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> References: <53F30A81.9090302@freebsd.org> <20140821110920.fecb365dda2129e5d21c351b@ddteam.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <se@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F659B0.1010602>