Puppy In-House Development

[Iguleder]

I'm building a 32-bit variant of DSLR through VirtualBox. So far, results look quite weird - there's a size difference of 4-8K between 32-bit and 64-bit packages.

Do you have any good explanation for this? I expected a 15%-20% reduction in size. I want to get DSLR's 32-bit edition smaller, somewhere around 70 to 75 MB (compared to the 64-bit edition, at 93 MB).

[Ibidem]

I'm building a 32-bit variant of DSLR through VirtualBox. So far, results look quite weird - there's a size difference of 4-8K between 32-bit and 64-bit packages.

Do you have any good explanation for this? I expected a 15%-20% reduction in size. I want to get DSLR's 32-bit edition smaller, somewhere around 70 to 75 MB (compared to the 64-bit edition, at 93 MB).

Is that installed size or compressed?
I thought that 10%-15% shrinkage (80-84 MB, if everything were code) was the high end of what you might expect.

Also, with 32-bit compatability, you should be able to chroot into a 32-bit environment, run setarch/linux32, and nothing can tell you're running 64-bit.

[Iguleder]

That's the installed size (binaries only).

EDIT: wow, it's simply horrible. The 32-bit ISO is smaller than the 64-bit one by just 1 MB.

[technosaurus]

I'm building a 32-bit variant of DSLR through VirtualBox. So far, results look quite weird - there's a size difference of 4-8K between 32-bit and 64-bit packages.

Do you have any good explanation for this? I expected a 15%-20% reduction in size. I want to get DSLR's 32-bit edition smaller, somewhere around 70 to 75 MB (compared to the 64-bit edition, at 93 MB).

If you removed -fPIC from your default CFLAGS that may have made a difference, its only needed for shared libs, not binaries (also -fpic is smaller)... Depending on the program, there could be a 49% size difference just because longs, pointers etc... that are not initialized to 0 which take twice as much space in a 64bit binary.... but if there are very few of those types you won't get much size difference at all.

Re: KMS
Not all framebuffer devices support it. Its easier to do one patch to make it friendlier for existing framebuffers than to add KMS to every driver in the kernel.


<sidebar>
Have you looked at the sources? Its appalling. 90% of them have direct cut 'n pastes of entire functions, many with little to no changes.
Here are 2 that other framebuffer drivers include if they don't have builtin versions of their own:
drivers/video/fbdev/core/cfbimgblit.c
drivers/video/fbdev/core/sysimgblit.c
Note the similarities and shared static const variables (some functions are exactly the same except white space). The Linux kernel is systemically plagued with this kind of garbage programming that defeats the whole benefit of using a monolithic kernel in the first place. I'd really like to see some of toybox's techniques applied to the kernel - I'm pretty sure it could result in nearly a 50% size reduction if not more (If you think I am talking out of my ass, just run uncrustify on the sources followed by duplo). Way too many common functions are included in the modules rather than being moved to lib/ (or they _are_ already in lib/ and just not used) and many large blocks of shared code could be converted to functions.
For that matter the video drivers are unnecessarily split into multiple different drivers (fb/video, drm, kms, ...) and could be unified. For the openGL stuff, there could be cfb*/sys* fallbacks that use Fabrice Bellard's tinyGL code for any unsupported functions (then even uvesafb could support openGL), but this could potentially break compatibility and thus may never be fixed in the vanilla kernel.
</sidebar>

[greengeek]

EDIT: wow, it's simply horrible. The 32-bit ISO is smaller than the 64-bit one by just 1 MB.

Given that a 64 bit instruction can obviously do twice as much work per cycle as a 32bit instruction then the 32-bit ISO should be twice the size of the 64-bit one.
Logical. Totally.

[technosaurus]

EDIT: wow, it's simply horrible. The 32-bit ISO is smaller than the 64-bit one by just 1 MB.

Given that a 64 bit instruction can obviously do twice as much work per cycle as a 32bit instruction then the 32-bit ISO should be twice the size of the 64-bit one.
Logical. Totally.

sarcasm aside, this can be true when optimizations are turned on ... there are many peephole optimizations that can convert several instructions into a single SSE* or other 64 bit instruction.

Currently these peephole optimizations are relatively few in number, but it is in the range of possibility to add a superoptimizer like STOKE into llvm's JIT compiler to continuously discover new ones using extra clock cycles in a parallel thread and store the results to a remote database for verification. This could be extremely beneficial to any program that uses this method for alphas, betas and release candidates so that the final version has the best (or at least better) optimizations. This is one of my possible candidates for a PhD thesis.

[Iguleder]

Just uploaded a fresh 32-bit build. It looks great - uses 24 MB of RAM under Qemu, with an emulated Pentium and 512 MB of RAM.

If you removed -fPIC from your default CFLAGS that may have made a difference, its only needed for shared libs, not binaries (also -fpic is smaller)... Depending on the program, there could be a 49% size difference just because longs, pointers etc... that are not initialized to 0 which take twice as much space in a 64bit binary.... but if there are very few of those types you won't get much size difference at all.

Interesting. I removed -fPIC - I'll try to rebuild both flavors whenever I find the time next week.

Not all framebuffer devices support it. Its easier to do one patch to make it friendlier for existing framebuffers than to add KMS to every driver in the kernel.

Of course it's easier, but that's a workaround, not a solution for this problem.

[technosaurus]

Of course it's easier, but that's a workaround, not a solution for this problem.

The whole KMS infrastructure was originally a workaround for specific vendor cards, so it makes sense that other vendors don't want to implement it themselves. I wonder if I could figure out a way to use the auto resolution code iff KMS is not supported.

The original thread is here:
http://www.murga-linux.com/puppy/viewtopic.php?t=78993

[Keef]

First attempt using 32 bit dslr-latest-i686-bios.
Tried booting from USB using isoboot. Got the following message:

Code: Select all

esas2r: driver will not be loaded because no ATTO esasr2 devices were found.
wdt: WDT status 255
eurotechwdt: timeout WDT timeout
eurotechwdt: initialising system reboot

Then it hangs.

Copied files to HDD and booted via Grub4Dos. Same result until adding acpi=off to kernel line - long pause after the message above though.
Touchpad works well, but USB mouse is very jerky.
Dillo launched but would not load any webpages (Lynx is OK). Tried the Dillo binary from PupNgo and that works correctly.

HP nc6120 Laptop
Chip description:
VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
Processor: Intel(R) Pentium(R) M processor 2.00GHz
Broadcom Corporation NetXtreme BCM5705M_2 Gigabit Ethernet

[Iguleder]

The Dillo part annoys me. What do you mean by "would not load any webpages"?

[Keef]

Ok, maybe that wasn't the best description.
Basically it would not respond when when any of the links were clicked, just stayed on the home page. No error messages.

EDIT: While what I said previously was true - I had a working internet connection and Dillo would not connect, I just tried again and it worked correctly.
However I made sure the connection was up properly first. Network does not start automatically. Ran dhcpcd eth0 - it takes about 30 seconds before the *.pid file appears in /run. Takes about the same time again before the command completes and cursor returns. Starting Dillo after that was successful, but don't know why it was playing up last night. I tried it again after internet was up, but still no joy.

[Iguleder]

Just rebuilt the entire thing without -fPIC - there's a 2 MB difference, which brings the 32-bit flavor down to 90 MB (without UEFI support). RAM usage is somewhere around 20 MB on my Eee PC.

The next logical step is to build DSLR-based, tiny and extremely lightweight Puppy

Keef: I'm removing all watchdog drivers, both because of immediate shutdown/reboot issues and because I think most users won't need them.

[linuxcbon]

hi Keef, what are your Grub4Dos boot options ? I cannot boot it, it stops at "searching for the home partition". Thanks

[Iguleder]

It doesn't need any boot options.

If you're booting from a really slow USB drive, add "sleep=5".

[Ibidem]

J
Keef: I'm removing all watchdog drivers, both because of immediate shutdown/reboot issues and because I think most users won't need them.

That's what watchdog drivers are meant for.
Basically, they wait n seconds for a reset, and if it doesn't happen in that time, the system is considered hung and it reboots.
So you'd need a daemon to do the resets; busybox inludes some tool related to this.

The theory is that this improves availability for stuff that people don't usually have the ability to reboot.

I believe there's a config option somewhere telling how many seconds to wait for a reset, but I don't remember what or where that is.
(Sorry to be so vague.)

[Iguleder]

I don't find these drivers useful enough for the average Puppy users. It's kinda weird that having them as built-in drivers causes an immediate reboot only on some machines.

[Keef]

@linuxcbon

This is what I started with:

Code: Select all

title DSLR
   uuid 9544e76c-4dc2-4023-97f5-bad2a907641d
   kernel /bzImage 

Run blkid in a terminal to get the uuid for your partition.

I also had to add acpi=off to the kernel line else I got the problems mentioned above.

Code: Select all

kernel (hdx,x)/bzImage 

also works (eg hd0,6) without needing the uuid line.

RAM usage is 25.4mb on my machine.

[linuxcbon]

ok it boots, but it took 5 minutes to copy the root file system to RAM. I used

Code: Select all

title DSLR FRUGAL
  root (hd0,0)
  kernel (hd0,0)/bzImage
  initrd (hd0,0)/initrd.xz

I think it takes time because I boot from ntfs , and looking kernel messages, many errors due to ntfs and fat fs, so kernel doesn't like it.

And then I am with the console, how do I start jwm ? It complain it doesnt find /dev/fb0 ,something like that...

[Iguleder]

First of all, what is initrd.xz? DSLR doesn't have or need that.

Second, booting from NTFS may work, but it's totally unsupported.

Finally, Your graphics card is unsupported - DSLR requires a framebuffer. What card is it?

Try to add vga=ask ("APPEND vga=ask") to your boot loader configuration.

[linuxcbon]

initrd.xz comes from dslr-10082014.iso
the card is hd6850.