Puppy Linux Discussion Forum

[Iguleder]

Hello guys, here's something I wrote: part-hotplug-handler.

As you know, I hate pup_event_frontend_d and want it to be replaced with a lightweight, udev-based replacement written in C.

So ... here's an example!

Currently, it detects partitions well, but the desktop icons are created in an endless column starting at (32, 32)

The architecture is modular:
- part-hotplug-handler is a process that should run once the user logs in. Build it with gcc -ludev part-hotplug-handler.c -o part-hotplug-handler. Whenever a partition is added or removed, it runs part-icon. It knows when things happen using udev's API.
- part-icon is a simple script that creates or removes desktop icons using ROX-Filer's XML RPC.
- mount-and-open is nothing but a script executed once the user clicks a desktop icon created by part-icon. This script mounts the partition and opens a ROX-Filer window.

Comments, ideas, anyone?

[sc0ttman]

Nice, how does this differ from the 'pup-volume-monitor' and its 'desktop-icons' util..? Can you provide a comparison?

[Iguleder]

- Previous solutions are polling, this one isn't. They just sleep for a given amount of time (a few seconds), then check /sys or whatever to find new partitions.
- Previous solutions are nothing but shell scripts. They do that polling using executables (for example, find, grep, cut, whatever), which is waaaaay heavier than using a function. This rule is true for any programming language (e.g in Python, using cat and popen() instead of of opening a file and reading it, is much slower).
- udev already knows which partitions exist, so previous solutions just "learn" this information again. This is incredibly inefficient and ugly. If udev knows all this, why don't we just ask it?
- This thingy doesn't replace pup-volume-monitor, which is makes it possible to see partitions in file manager. It only creates desktop icons, but you could merge the two.

[Karl Godt]

pup_event_frontend_d had cost me some teeth, too :BIG LOL:

Iguleder,
looking at it, mount-and-open should replace drive_all .

Not sure if mountpoint is included in Puppies by default, probably a busybox applet ?

A small hint : Never had any problems with mount to automatically detect the fs type until recent times, but shortly had some troubles with partitions being incorrectly assumed (jfs,ext4) .

[Iguleder]

You can always use mount and grep ... but we're after a clean and efficient solution, aren't we?

And yes - I agree; recent versions of mount are pretty good at guessing. guess_fstype, disktype and all those crappy hacks can be dropped.

[Karl Godt]

[akash_rawal]

Tried it.

Works very well for first attempt. And much faster than anything else

Well commented and easy to read code too

A small tip: At part-hotplug-handler.c:136, If you aren't planning to add more file descriptors you can remove the select() function call and save an overhead of one system call.

[Iguleder]

Nope, cannot do this - I want the process to be blocked by a system call until an event occurs (e.g so the process gets skipped by the scheduler, instead of wasting CPU cycles - that's the main benefit compared to a script).

I tried to set O_ASYNC on the file descriptor, but for some reason it does not emit SIGIO.

[akash_rawal]

[jamesbond]

Nice contribution as usual, Iguleder.
Just a question - since we already have udevd running in puppy anyway, why don't just use udev rules to create all these Rox icons? That's what I did in earlier Fatdogs.

[akash_rawal]

[Karl Godt]

Surprise .. mountpoint seems to be enabled in Puppy since Lupu 5 in busybox and exists as binary or symlink in /bin .

[Iguleder]

So inefficient!

The second pipe is redundant.

[Karl Godt]

And problematic if spaces in filename

[Karl Godt]

First Success in Compiling on Puppy-4.3 :
http://pkgs.fedoraproject.org/repo/pkgs/udev/udev-142.tar.bz2/3edc4cf383dccb06d866c5156d59ddd5/

141 was missing udev_monitor_filter_add_match_subsystem_devtype