hal scripts cannot do INT32

[danny at mailmij.org]

On Wed, Jun 10, 2009 at 12:51:42PM +0200, Kay Sievers wrote:
> On Sun, Jun 7, 2009 at 13:35, <danny at mailmij.org> wrote:
> 
> > The first issue is a race condition. Apparently, on the moment the backlight device
> > is created, hal tries to read the maximum brightness. Even although there is only a
> > short code path between device creation and the set of the max brightness, apparently the
> > kernel gets preempted, and hal reads 0 from sysfs.
> 
> Are you sure, the sysfs file is already created that time or it possibly isn't?
Not sure, although I would have expected it would error otherwise. Will check once I tried to move my system
to an external disk and get back on this.

> 
> > The problem is
> > that although shell scripts can do exit ${value}, with a value over 256, this value
> > can not be realiable read by reading the child exit status in C. Only a 16 bit integer
> > can be read like this, and thus my hal version is wrapping the 1000 possible brightness
> > levels returned by sysfs.
> 
> You mean 8 bit, I guess?
>
Yes, sorry I mixed up. Well, 16 are read but only 8 are for the status. see the def of WEXITSTATUS.
 
> > I'm not sure if the plan is to remove all the shell scripts and move to C, or that everybody is sue 16 bits are enough even although the api specifies a 32 bit int.
> 
> We are currently moving away from HAL to DeviceKit, so any major
> changes in HAL seem unlikely. For new stuff DeviceKit-power,
> DeviceKit-disks should be focused on.
OK I see.I briefly checked it out. As long as it doesn't read exit statuses of scripts (which it doesn't seem to), I guess it is safe from this problem.

As the nouveau driver is as yet unreleased, I think I'll keep the support for powerpc panels on 1000 brightness levels, so it only be compatible with new hal versions or devicekit. (once problem 1 is fixed).

Danny