Thread Tools
Posts: 1,910 | Thanked: 2,450 times | Joined on Feb 2011
Getting the HAL/mounting discussion back in here:
Posted by szopin in libglib thread:

udisks requires libglib 2.31.13, available on Precise (.18) in armel flavour. Going to backup and try forcing it later on today. If that is just 'not going to work' let me know guys, reverting backups is not always successfull and would hate to have to resort to flashing/reinstalling everything


Wait, hold on there.
You'll need udisks, a very new udev and take out HAL.
That last one will probably break Maemo.

So there is no way to keep HAL for everything except storage mounting? Was hoping udisks could be used for mounting whole fs from /opt and keep HAL for the rest as it seems a gargantuan task
Posts: 1,225 | Thanked: 1,899 times | Joined on Feb 2011 @ Quezon City, Philippines
No, no, wrong, just no.
udisks mounts the sdcard for us. We define the eMMC (home, opt, MyDocs and hopefully /usr mounts) in fstab.
Maemo being Maemo, it's rootfs is mounted by the kernel at boot-time.

And udev works together with udisks to expose the devices to the system. No going around that. Part of the package.
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
Posts: 1,910 | Thanked: 2,450 times | Joined on Feb 2011
Ok, so how could DeviceKit be possibly used to save rootfs space?
Estel's Avatar
Posts: 5,029 | Thanked: 8,557 times | Joined on Mar 2011
Originally Posted by geneven View Post
Those who "never" had this problem probably joined in 2011 and I wonder if they ever even read the long threads about this problem that were produced just before the N900 was released to the common people.
Come on, it's pure sophism. I'm perfectly aware of "early adopters" problems, but we're far away from times, when optification was arcane magic.

Of course, it's is obstacle for developing on device (yet, instructions on how to use whole 32GB eMMC as root may apply here), but to be honest, szopin's point about compression is much more interesting, IMO. Compression is a fact AFAIK, but isn't it possible to measure NAND actual speed (even including compression) just like we measure eMMC speed? I.E random access and raw read/write, separately? That would be much more appropriate, than "feelings" about something starting faster or not.

I'm quite convinced, that huge speed loss due to transparent compression in NAND is a myth, but it's also pure assumption - based on the fact, that compressing "bandwidth" based on CPU power is still much wider than writing capabilities of NAND (same apply for encrypted swap via TrueCrypt - despite encryption eating CPU, it doesn't make speed to suffer in any way, as it's still encrypting faster, than eMMC is able to write) - at worst, it may result in minimal speed lost on 100% CPU load (and if compression doesn't have highest/high priority).

N900's aluminum backcover / body replacement
N900's HDMI-Out
Camera cover MOD
Measure battery's real capacity on-device
TrueCrypt 7.1 | ereswap | bnf
Hardware's mods research is costly. To support my work, please consider donating. Thank You!

The Following 2 Users Say Thank You to Estel For This Useful Post:
Posts: 1,910 | Thanked: 2,450 times | Joined on Feb 2011
Estel: Yeah I know this is just as reliable as xxxpatch users' testimonies, but do me and yourself a favour: close all microB windows, click on microB and watch the time, takes around 0.5 second for the bookmark window to open up. Move microb-engine to opt, repeat the above, starts instantly. As startup loss of half a second is not even worth arguing about random read/writes etc. doesn't matter as it is not random but ~5MB worth of read/decompression. It does visually for me take more time to start and for you most likely also will. Lets not argue about non-issues.

The Following 3 Users Say Thank You to szopin For This Useful Post:

Thread Tools

Forum Jump

All times are GMT. The time now is 18:27.