So I have a python script that emulates an ESC_KEY on pin 17 (Raspberry Pi).#!/usr/bin/env python#Imports for Pins,inputimport RPi.GPIO as GPIOimport uinputfrom time import sleep#Setupkey_events=( uinput.KEY_ESC, )device=uinput.Device(key_events)GPIO.setmode(GPIO.BCM)GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP)#MAINwhile True:   GPIO.wait_for_edge(17,GPIO.FALLING)   device.emit(uinput.KEY_ESC,1)   sleep(2)   device.emit(uinput.KEY_ESC,0)Is there an easy way to set this up as a kernel module, or does anyone have some good documentation to create this kernel module? Do I need to rewrite it using C?It seems as this is eating alot of resources when running in python, I'm hoping it would be less a strain on the system when run as module.
From Python script to Kernel Module
kernel modules
Is there an easy way to set this up as a kernel moduleProbably not.  Also, that might be kind of contra good design principles, because what you have seems like more of a userspace app; there's a kernel driver lurking in the background of it anyway.1It seems as this is eating alot of resources when running in pythonConsidering it sleeps most of the time, that's not a good sign; maybe you should be more specific.  The stuff I've done with the rpi pins is all I2C based in C or C++ using the kernel interface, and something simple like this wouldn't be more than 1 MB RSS or use any noticeable CPU time.Do I need to rewrite it using C?Re-writing it in userspace C might solve your problem, if the problem is resources (WRT kernelspace code, yes, that is C and asm only).  However, python should not be all that bad -- there's obviously no performance issue here.  Again, you should describe the problem in more detail.The RPi.GPIO module is written in C, you might want to take a look at that.  However, IMO if you don't know the language already and don't have an interest in it otherwise, it is not worth learning just for this.You could also try using the (language agnostic) existing kernel interface in python directly, instead of RPi.GPIO; it's simply a matter of reading from and writing to file nodes in /sys/class/gpio.  You'll find more stuff about that online if you search and at the raspberry pi exchange. The DMA hack mentioned in the footnote may have an advantage over this if you are trying to do things at a very high frequency, but that's not the case here (and I'm dubious as to how useful it really would be in this sense, because it is still a pure userland entity and subject to kernel latency).1 Actually that's not true in this case -- RPi.GPIO uses a direct memory address hack like this one; I think the C level wiringPi modules also work this way.  That's stuff that would make a good kernel module, except the kernel already has a gpio module with a userland interface.  I imagine the justification for the DMA hack is that it seems more efficient (and more interesting to write).