Unix Domain Sockets

For a very long time I have had it in mind that Puppy needs a more formal way of doing InterProcess Communication (IPC). I have thought about it over the years, ways in which it would be useful, and ways in which it could be implemented, but nothing ever happened.

I did at one time work on a daemon named 'pup_event_backend_d' and I had a vague idea that it could be a kind of server for interprocess communication, including making some of the tray applets that currently use polling technique, more efficient. Also, some utilities that use files in /tmp for message passing and synchronization could also become more professional if they use an IPC technique.

My current iteration of thinking about this has actually got to the stage of conceptualizing how it could all fit together, and as part of this I investigated various IPC methods available in Linux and their merits and demerits.

One interesting IPC method is kernel-dbus, but that is sometime off before it gets merged into the kernel. I did play with a D-Bus server-client, but decided that other techniques are more efficient, and besides I would still like to be able to build a Puppy (ex: Wary) without D-Bus.

I narrowed it down to Unix Domain Sockets, named pipes (fifos) or System V message queues.

I decided to go for Unix Domain Sockets, one reason being that unlike pipes they are bidirectional, and secondly I already have some familiarity of the C functions -- as I have done some coding for Netlink sockets, which use many of the same functions.

Here is a very good intro page on Unix Domain Sockets:
http://beej.us/guide/bgipc/output/html/multipage/unixsock.html

...I have been playing with the example programs from that link.

I must emphasise that this is just playing around at this stage. I might decide not to take it any further.
I'll post about any further developments.

Note, the pup_event_backend_d structure that I have been thinking about, would have both a Netlink Socket and a Unix Domain Socket. Clients will be able to request and receive relevant preprocessed kernel uevent information.
I have tentatively mapped out how such a program will be coded.

For information about the C functions:
http://www.gnu.org/software/libc/manual/html_node/Function-Index.html

Read more...

JWM, devtmpfs, fixes

We were discussing issues with JWM here:
http://bkhome.org/archive/blog2/201306/raring-puppy-quot57alpha1quot.html

Fix for JWM "layer:" option:
http://bkhome.org/fossil/woof2.cgi/info/7115d873ba

There is also an issue with wrong permissions and ownership of some device nodes in the latest Raring Puppy alpha1.

Fix for device nodes:
http://bkhome.org/fossil/woof2.cgi/info/e743ffbb31
http://bkhome.org/fossil/woof2.cgi/info/2abc972507

Read more...

Woof: built Raring 5.6.92

I have committed the latest Woof, as used to build Raring Puppy 5.6.92 (see previous blog post).

Three most recent commits (latest first):
http://bkhome.org/fossil/woof2.cgi/info/ab73ad4c6d
http://bkhome.org/fossil/woof2.cgi/info/faa913cdd5
http://bkhome.org/fossil/woof2.cgi/info/f41872ecf5

Read more...

Fix for overlapping drive icons

Some Puppy users have reported the desktop drive icons getting created on top of each other.

There was a lot of confusion in the Forum discussion, until it became clear that it only happened when the user changed the ROX-Filer "placement granularity" -- the default of which is "fine" (2 pixels).

Once the cause became clearer, K Godt, npierce, MinHundHettePerro and others analysed the problem and proposed solutions, or at least steps to reduce the problem.

npierce has summarised it nicely in a post in this thread, with two possible partial solutions:
http://murga-linux.com/puppy/viewtopic.php?t=86137&start=225

I have implemented #3. Woof commit:
http://bkhome.org/fossil/woof2.cgi/info/faa913cdd5

Tags: woof

pup_event_frontend fixes

charlie6 reported disappearing drive icons:
http://bkhome.org/archive/blog2/201306/new-pupeventfrontend.html

I have also encountered a problem. My Optus 3G USB stick is supposed to show up on the desktop as a CD drive (it doesn't have mode-switching). But is didn't.

I think it is fixed now. I found a bug in pup_event_frontend_d.bac, had to recompile for x86 and arm, and bugs in script frontend_change.

Woof commits:
http://bkhome.org/fossil/woof2.cgi/info/55710737f7
http://bkhome.org/fossil/woof2.cgi/info/8133d4a3cd
http://bkhome.org/fossil/woof2.cgi/info/dbc067820d

Read more...

Kernel 3.9.5 experiment

I compiled the 3.9.5 Linux kernel, with devtmpfs enabled. This kernel also loads module firmware, another task that was previously handled by udev (and pup_event_backend).

So, there are two features of udev that are now done by the kernel:

1. Dynamically create/remove device nodes in /dev
2. Load module firmware.

I built Raring Puppy with this kernel, and with the 'kmod' package instead of 'module-init-tools', and with the 'eudev' package instead of udev (or systemd).

I had compiled it with PAE enabled and i586, however I am right now recompiling it for a i686 (Pentium Pro) minimum CPU, which, as far as I am aware, would be the case for PAE-capable CPUs.

The devtmpfs kernel, kmod and eudev all work well.

The next thing that I have to do is revise the pup_event_backend code, in light of the new capabilities of the kernel.

Read more...

Universal Installer bug fixes

I have fixed some bugs in the Puppy Universal Installer, when do a full-HD installation.

1.
Puppy now has /run, which is only a symlink to /tmp. Eudev is hardcoded to use /run, and fails without it. The full-HD installation did not have /run, fixed.

2.
I installed Puppy to a partition that had Ubuntu already installed, and the Universal Installer did not offer to wipe the partition, meaning that the Ubuntu files were all still there afterward.
I have changed the code to always ask if you want to wipe the partition.

3.
After copying the Puppy files to the destination partition, there is a chroot into it to run /etc/rc.d/rc.update. This requires /dev/console and /dev/null in the target filesystem, however the new architecture with a devtmpfs-enabled kernel has nothing in /dev. Fixed.

Woof commit:
http://bkhome.org/fossil/woof2.cgi/info/26df6c91e1

...there is also a fix for 3builddistro, to work properly with the 'depmod' of the 'kmod' package.

Tags: woof

RPi: building in Woof: skeletons

I still haven't fixed Xorg segfaulting in "Raspberry Puppy", latest pup built from Raspbian DEBs for the Raspberry Pi.

But, I have uploading two essential ingredients, so that now anyone can use Woof to build their own "Raspberry Puppy".

Kernel PET (15.6M):
http://distro.ibiblio.org/quirky/arm/pet_packages-armv6/linux_kernel-3.6.11-raspi-29may2013.pet

SD-card skeleton image:
http://distro.ibiblio.org/quirky/arm/sd-skeleton-images/raspi-sd-4gb-skeleton-ext4_nojournal-29may2013.img.xz
http://distro.ibiblio.org/quirky/arm/sd-skeleton-images/raspi-sd-4gb-skeleton-ext4_nojournal-29may2013-README.html

...regarding the SD-card image, you don't download it yourself. The 3builddistro script in Woof looks online and offers to download it.

Note that the SD-card image is a skeleton. It doesn't have Puppy, nor a Linux kernel.

Tags: woof