Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Aug 2014 12:27:43 +0200
From:      Stefan Esser <se@freebsd.org>
To:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons
Message-ID:  <53FC611F.3030407@freebsd.org>
In-Reply-To: <20140824000005.GL71691@funkthat.com>
References:  <53F30A81.9090302@freebsd.org> <20140824000005.GL71691@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 24.08.2014 um 02:00 schrieb John-Mark Gurney:

Thank you for the review and the comments.

I have prepared a patch for rc.d/syscons, which I'll post for
review in a new thread.

> Stefan Esser wrote this message on Tue, Aug 19, 2014 at 10:27 +0200:
>> 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 ...)
> 
> Per compatibility, leave it names syscons until the old one is
> deprecated..  No point is having two copies....

Agree.

>> 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, and then if/when syscons is removed, we remove the warning...

I have that implemented. There is no warning but a message, that the
keymap entry in rc.conf should be updated.

>> 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 ...)
> 
> Yes...

Is implemented in the patch ...

>> 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.)
> 
> Yes, and make sure to print out a [big] warning to have them update
> their config...

Hmmm, the warning is not really big, right now.

This could easily be changed, but I'm afraid that it will still scroll
by before the user notices it.

>> 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.)
> 
> I would say no, since they are similar compatible...

Yes, and with the lookup of the vt/keymaps name that matches a
syscons/keymaps file, it is not much use, anyway.

> The biggest issue is if someone has a custom keymap...  If this
> is the case, you might want to point them to a guide/your script
> for converting their custom keymap... Yes, I doubt many people are
> using a custom keymap, but they are probably out there...

Yes, I'll add a message, that the specified keymap could not be loaded.
As of now, the lookup of the vt keymap name does not consider the path
specified by the user. I did not want to further complicate the code
(with checks for an absolute path or whether a keymap really exists in
syscons/keymaps before trying to translate the name).

Let me know, if you think this should be added ...

> btw, thanks for your work on bringing FreeBSD into the 21st century!

It was me a pleasure to fill a small gap that had been left ;-)

Best regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53FC611F.3030407>