I am thinking about the structure of pup_eventd. Nathan's idea that it should have a backend and a frontend is probably the way to go. I think that I'll start the backend daemon in rc.sysinit, so that it can take care of firmware loading at bootup. The frontend will start when X starts. I'll see if I can get a working implementation of that today.
I have fixed PupScan, my hardware/modules information GUI application (see System menu) to work with all modules present. With the previous fetch-on-demand system, I had to implement a very awkward arrangement of the module dependency files. Puppy had /lib/modules/modules.pcimap.<kernver>, modules.usb.<kernver>, modules.dep.<kernver> and modules.isapnpmap.<kernver> -- these are copies of the original files modules.pcimap, modules.usb, modules.dep and modules.isapnpmap that are inside /lib/modules/<kernver>/ when all modules are present. Now, PupScan, and indeed all scripts in Puppy, can use the original dependency files.
Apart from being awkward, those copies are quite big files -- 'du' shows them to total 748KB! (22.214.171.124 kernel, 126.96.36.199 would be bigger) So, having duplicates in the pup_xxx.sfs file is wasteful.
Thinking ahead, as I am planning to go to Perth on Friday the 5th of June, I'll aim to upload 4.1alpha2 about the 6th - 7th. It should hopefully be a bit more mature than the alpha1 and ready for wider testing.
No comments posted yet.