Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Jay Estabrook (Jay.Estabrookhp.com)
Date: Mon Apr 28 2008 - 11:40:38 CDT
Is that just a polite way of saying "you DO ramble on"??? ;-}
But back to the original problem you are having with dbus and hal.
I HAVE duplicated it, at least on my PWS600 (not on DS15, and I've
yet to try others). Still don't understand why the machine type should
be an issue, but stranger things have happened.
This is with my unaligned-access-free (just say "NO" :-) dbus
and hal RPMS. Nice and clean, but NOT working... :-(
I'm going to try starting each up manually with (hopefully) verbose
messages to see if some indication as to the problem will show up.
I'll keep you posted...
Steven Moix wrote:
> Heh! Thanks for this very complete and clear explanation :)
> On Sun, 2008-04-27 at 11:05 -0400, Jay Estabrook wrote:
>> I knew it was too early on a Sunday morning for this... ;-}
>> Estabrook, Jay wrote:
>>> The poor programming practice (hal) arises from assuming that all
>>> architectures have a natural boundary of 32-bits. Something like
>>> the following are indicative:
>>> pointer = (void *)((((char *)address) + 3) & ~3);
>> Should be:
>> pointer = (void *)((((char *)address) + 4) & ~3);
>> which rounds UP to the next 32-bit natural boundary.
>>> Better is:
>>> #define SZM (sizeof(void*)-1)
>>> pointer = (void *)((((char *)address) + SZM) & ~SZM);
>> And this should be:
>> #define SZ (sizeof(void*))
>> #define SZM (SZ-1)
>> pointer = (void *)((((char *)address) + SZ) & ~SZM);
>> which also rounds UP.
>> Now back to the funny pages... ;-}
>> axp-list mailing list
> axp-list mailing list
axp-list mailing list