lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 26 Nov 2009 22:34:55 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Jarod Wilson <jarod@...sonet.com>
Cc:	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson <jarod@...sonet.com> wrote:
> This part... Not so wild about. The common thought I'm seeing from people is
> that we should be using setkeycode to load keymaps. I mean, sure, I suppose
> this could be abstracted away so the user never sees it, but it seems to be
> reinventing a way to set up key mapping when setkeycode already exists, and
> is used by a number of existing IR devices in the v4l/dvb subsystem (as well
> as misc things like the ati rf remotes, iirc). Is there some distinct
> advantage to going this route vs. setkeycode that I'm missing?

The configfs scheme and keymaps offer the same abilities. One is an
ancient binary protocol and the other one uses Unix standard commands
like mkdir and echo to build the map. You need special commands -
setkeycodes, getkeycodes, showkey, loadkeys, xmodmap, dump-keys to use
a keymap.  I've been using Linux forever and I can't remember how
these commands work.

Keymaps are a binary protocol written by Risto Kankkunen in 1993.
Configfs was added by Oracle about two years ago but it has not been
used for mapping purposes.

It's another discussion, but if IR goes the configfs route I'd
consider writing a patch to switch keymaps/keycodes onto the configfs
model. It is a huge advantage to get rid of these pointless special
purpose commands that nobody knows how to use. I'd keep the legacy
IOCTLs working and redirect the data structure to a configfs one
instead of the existing structure.

The same idea is behind getting rid of IOCTLs and using sysfs. Normal
Unix commands can manipulate sysfs. IOCTLs have problems with strace,
endianess and the size of int (32/64b).

-- 
Jon Smirl
jonsmirl@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists