I explored the /sbin/pup_event_backend_* files, and as far as I can understand I think it gets almost entire hardware information from udev.
If we rewrite the event manager backend in C, we get the following advantages:
- Faster execution: Programs written in compiled languages obviously run faster.
- No synchronization problems: I also observe synchronization explicitly forced through pup_event_backend_modprobe_protect. Such thing is already achieved in C without synchronization primitives.
- pup_event_backend and volume monitor backend can be combined together resulting in a single process efficiently managing module and firmware loading and at the same time managing drive hot-plugging events and broadcasting them to puppy's programs as well as GIO applications.
For the frontend, I think the following design changes:
- Icons can be drawn on a separate window. This means drive icons will work with any desktop manager or pinboard, and even with no pinboard at all.
- Use of GIO API instead of polling sysfs. This means reusing polling results of the backend as mentioned before and also much better response to drive plugging and removing. This also means we can readily start off with development of frontend without waiting for backend's GIO modules to be complete. (In that case the frontend has to be tested on Ubuntu, obviously)