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.

- 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._________________My homepageMy GitHub profile

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) ._________________«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal

There should be a enable everything busybox in the initrd.lz and be copied like the kernel drivers into the /pup_new/bin directory. At least I will do that if I manage to kick my ass, which rarely happens .

Iguleder wrote:

... but we're after a clean and efficient solution, aren't we? Very Happy

Your squeeze-pup 005 from anno 2010 has the mountpoint full binary as I found out . Still runs on atom D525 . Very Happy .

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).

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).

On removing select() stuff, udev_monitor_receive_device() does the blocking job when there's no data to read. That way you do the same task in just one system call than two system calls.

There's no wastage of CPU cycles, there's conservation instead

Iguleder wrote:

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

Strange. Probably that's due to BSD features have problems with netlink sockets.

But anyways udev doesn't seem to support asynchronous reading of events. You cannot wait for anything more other than udev events in same thread.

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._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread

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.

That'll work better if daemon isn't storing any long-term useful information in memory.

I'm now wondering whether there's a fuel-efficient way of arranging icons so that they don't collide with each other.

The logic is complex enough to drive me away from idea of desktop drive icons.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum