Reply
Thread Tools
Posts: 1,384 | Thanked: 1,529 times | Joined on Feb 2011
#31
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

Hurrian:

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

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,876 times | Joined on Feb 2011 @ Quezon City, Philippines
#32
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
@imblying, working on Glacier for Nemo.
 
Posts: 1,384 | Thanked: 1,529 times | Joined on Feb 2011
#33
Ok, so how could DeviceKit be possibly used to save rootfs space?
 
Estel's Avatar
Posts: 4,903 | Thanked: 8,148 times | Joined on Mar 2011
#34
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).

/Estel
__________________
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,384 | Thanked: 1,529 times | Joined on Feb 2011
#35
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:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 07:46.