Pmount auto-refresh

I have got it working nicely now.

I found some skeleton C code for reading kernel uevents to stdout. This is a very small program, just 3.5KB. I have named it 'hotplug2stdout'. I still had the weirdness mentioned in the last post, and after a full day puzzling over it and looking at alternatives (inotify, dnotify, fam, etc.) I eventually thought of a weird solution to solve the weird problem.

This is the start of my light-weight alternative to udev, dbus and hal

Note, the important thing about the new 'pup_ueventd' is that it does not poll. It goes to sleep and uses virtually no resources until woken up by a relevant event from 'hotplug2stdout'. This is the whole point of the exercise. Currently in the tray we have applets that are looping, polling something, which uses up the CPU time. There is also a background daemon, savepuppyd, that does polling. I am aiming to reduce the number of applets that perform polling.

To minimize CPU usage, those applets may have a fairly slow polling loop, say 2 - 5 seconds -- but that also makes them slow to respond to an event. Whereas, the new uevent-based system responds immediately.

Pmount does not poll, until now it had to be updated manually, by clicking the Refresh button. Now it refreshes automatically, if running.

---

Comments

Thanks


zdrv solution
Username: kirk
" Barry, How about this as a solution to having the kernel modules in the initrd.gz? Use the initrd as the zdrv file. To do this you would have to leave the initrd unziped. This adds about 600k to the normal 4.0 initrd. Your big initrd has the kernel modules compressed, so they shouldn't add to that number. Then use your modprobe script to extract the module you need from the initrd cpio archive. If you cd to / and type: cpio -di "lib/modules/2.6.25/kernel/crypto/cbc.ko.gz" < /mnt/home/4.0/initrd (or where ever your initrd is.) This will create the needed directories and put cbc.ko.gz from the initrd to /lib/modules/2.6.25/kernel/crypto/. Also, by having all the modules in the initrd you might need a way of blacklisting a module as a boot parameter.

The nevent code
Username: BarryK
"Nathan, I'm still working on it, but pup 4.1alpha1 is very close, maybe 1 - 2 weeks. That's the plan anyway.

hotplug2stdout code posted
Username: BarryK
"For anyone interested, hotplug2stdout C monitor app: http://murga-linux.com/puppy/viewtopic.php?t=28888

Re: Re: zdrv solution
Username: kirk
"Yes, I was thinking that gziping the initrd would not be worth the slowdown for 600k, but I forgot about the firmware. The firmware uncompressed would add ~4MB. Slow is probably OK for how often it would be used. Might need some kind of Xmessage to let the user know it's doing somthing. If it's too slow, I guess ~4.6MB added to the ISO isn't too bad. By the way nice work with 4.00. Giving the kernel access to all the modules at boot and your udev-ish developments makes 4.01 look very interesting.

re:hotplug2stdout code posted
Username: Everitt
"Ok, I couldn't sleep, so I had a bit of a play with the code. It would seem that adding 'fflush' rather than a second printf has the desired effect. I've posted to the forum thread, including some slightly tidied source code (commenting out things I didn't see the point off really. Sorry, as I said, I can't sleep. :) )

Event Manager / Pmount conflicts
Username: dogone
"I realize this belongs in the forum. But the forum is down and the following is important. All regards Alpha 4 (404) with Aufa in force. Pmount and Event Manager appear to confuse one another. Event Manager reports Pmount's initial floppy mount. but does not report (remains "MNTD") all subsequent floppy umounts - whether performed by Pmount or Event Manger itself. Also, Pmount's need of manual refresh causes it's mount status to stale, making possible an attempt to mount (via Pmount) a floppy already mounted by Event Manager. Pmount then flags an error. Thus, we need to: - fix Event Manager's stuck mount indication. - have Event Manager force a Pmount refresh/restart.

Tags: puppy