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.

A note about SD cards. There was a recent bug report from someone that their SD card wasn't working, then they found it was working. I have the same problem. This seems to be a bug in the driver -- I hope that when I move to the 2.6.25.x kernel this will be fixed. For now, if I plug it in and it isn't recognised, I just keep trying, unplugging and replugging, and eventually it suddenly starts to work. There seems to be some conflict with plugging in other devices -- in my case a USB pen drive.

Posted on 8 May 2008, 23:32


Posted on 8 May 2008, 23:39 by coolpup
Excellent work, Barry.

Posted on 9 May 2008, 3:26 by nfisher
Very cool
Any chance of getting a look at the code you mention?

Posted on 9 May 2008, 4:19 by kirk
zdrv solution


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.

Posted on 9 May 2008, 7:54 by urban soul
looping, polling...
This is unbelievable! All these tray-apps... I don't like them. How is 'sleeping' and taking no CPU carried out exactly? Anyway - this way I can check if a wireless NIC is plugged in eg. ... or a cable plugged in. Or memory attached. It's gimmick - to be honest - but a very nice one! Everybody wonna have it!

Posted on 9 May 2008, 8:01 by BarryK
Re: zdrv solution
Kirk, yes, that thought had crossed my mind. If initrd.gz is compressed, initrd.gz, then it could be piped through gunzip then into cpio -- but I guess if it is 20MB then that is going to be slow. Although, it is only a one-off thing for fetching a module.

Posted on 9 May 2008, 8:07 by BarryK
The nevent code
I'm still working on it, but pup 4.1alpha1 is very close, maybe 1 - 2 weeks. That's the plan anyway.

Posted on 9 May 2008, 8:03 by BarryK
hotplug2stdout code posted
For anyone interested, hotplug2stdout C monitor app:

Posted on 9 May 2008, 8:38 by kirk
Re: Re: zdrv solution
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.

Posted on 9 May 2008, 10:23 by Everitt
re:hotplug2stdout code posted
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. :) )

Posted on 23 Jul 2008, 6:16 by dogone
Event Manager / Pmount conflicts
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.