option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files

[Harald Schmalzbauer]

 Hello,

currently I can't compile a kernel on a 10-stable machine with
differtent default keymap.
Reason is, that the k*map.h file gets generated at compile time, coded
in sys/conf/files.arch.

For any reason, on my 10-stable build machine, kbdcontrol(1) does look
for maps in /usr/share/vt/keymaps, although usr.sbin/kbdcontrol/path.h has
#define KEYMAP_PATH      "/usr/share/syscons/keymaps/
I guess it's because I have kern.vty=vt

Further guess is that I can build the kernel by setting 'env
KEYMAP_PATH=/usr/share/syscons/keymaps' for kernel configs having
*KB*_DFLT_KEYMAP set to syscons keymap name.

But I see some problematic cases in the way the neccessarry header files
gets generated.

First, I think that reading keymaps from the machine's installed maps
instead of the ones which are in the sources is not optimal.
Maybe it was intentional set to read machine's keymaps to be able to
compile a kernel without userland sources?!? But since 9k6 Modems and
ctm are obsolete, I can see no good reason any more.

Next is that buildkernel depends on kbdcontrol(1) on the build machine.
Don't know actually how this can be improoved, one must be able to
compile a kernel without userland, so there's most likely no obj tree
where we could use another kbdcontrol(1).

But my real problem is, that my building machine has to have the same
console like the one, I build a kernel for.
I guess searching in both paths (syscons/keymaps/ & vt/keymaps) if
KEYMAP_PATH is not defined should be implemented (in ys/conf/files.arch)
if the way the header files gets generated is the right one.

What would habben if I compiled a syscons default keymap into the kernel
and use vt? Or vice versa?

Thanks,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140914/a1193f35/attachment.sig>