Hello everyone, my name is Alessandro Osima and I'm a computer science student at Università degli Studi di Milano, Italy (second year, equivalent to bachelor). I would be very interested to participate in this year Google Summer of Code and I'm developing the concept of an application with the beagleboard open source organisation (http://beagleboard.org/).
The project aims to build a new kernel space interface for char device communication with userspace throughout files representing all kinds of character devices located into the /dev directory. This project was initially focused on offering a simple iio drivers debug interface with userspace but thanks to the advice by my would-be mentor Hunyue Yau, I turned to build a more robust and general interface. For this reason I started to look at evdev as a possible replacement. The problem with evdev is that it's heavily entangled with the input subsystem, especially in the initialisation and removal phases. Furthermore adding iio specific stuff to evedev would likely transform it into a poorly engineered subsystem. Therefore I agreed with Hunyue to create an entirely new module (let's call it nevdev) free from all the dependencies which evdev has with the input subsystem. The basic approach woud be the same as evdev, that is creating files in /dev, so that userspace can easily communicate with them throughout file i/o. While evedev directly handles file operations with input devices, nevdev would redirect all file operations on the subsystems that registered the devices. This way it could interact with any kind of character device. For example let's say that iio needs a new userspace interface for it's VCNL 4000 drivers. What iio does is asking nevdev for a new file in it's /dev/nevdev directory and passing it's own file_operations structure. Nevdev then creates and registers a new file in /dev/nevdev (named for example nevdev0) and every time userspace reads or writes to it nevdev receives the callbacks and calls the functions previously registered by iio. In other words every subsystem, not only iio or input_core can implement its own events and ioctls calls offering a really abstract interface. Following is an overview of the api possibly exposed by nevdev. Like a lot of other kernel subsystems nevdev will expose the usual register/unregister functions -int nevdev_register_interface(nevdev_handle * interface, struct device * dev) -void nevdev_unregister interface(nevdev_handle * interface) the nevdev_handle is a structure containing some nevdev related stuff like a spinlock a cdev and a device structure, the drivers will have to register two things, a file_operations structure and their device_core device structure. -struct nevdev_handle* nevdev_allocate_struct(struct file_operations * fops) this function will allocate nevdev_handle and place fops inside it. Internally nevdev will have a list of nevdev_handle corresponding to all the registered devices. Every time a new device is registered with int nevdev_register_interface(nevdev_handle * interface) nevdev will: 1:create a new device_core struct device using dev (the second argument in nevdev_register_interface) as a parent and a nevdev global device class as the device class, this way all the newly registered devices will stay in /sys/class/nevdev ready to be exported to /dev/nevdev by udev 2:create a new cdev character device and link it with the fops file_operations struct passed in nevdev_allocate_device. 3:register both with input_core, the hotplug event resulting from this will be intercepted by udev thanks to simple script and new nodes will be created in /dev/nevdev. This approach is very similar to the one evdev currently use. I believe nevdev will have its own dinamically allocated major number with all the minors corresponding to every newly registered device. Every time a file_operations syscall arrives it will be first intercepted by nevdev and then sent to the selected device via the registered file_operations struct. This is done in case we need to do some housekeeping (like when we receive an open() or release() call) and because nevdev will offer some global ioctls events for subsystem wide informations. Nevdev will of course reside in its own separate kernel module. I would kindly ask your opinions about this proposal and would be very grateful for any comments and suggestion. Thank you for reading this post, please to not hesitate to ask for any clarification. Regards, Alessandro Osima. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
