hal scripts cannot do INT32

[danny at mailmij.org]

Hi,
recently I spend some time on adding some powerpc specific brightness code 
to the nouveau drivers. When doing this I found 2 issues in the current
way hal handles the backlight interface.

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. Putting in some sleeps in the hal
code helps, but is hardly a reliable fix. I am not sure if the specification allows to 
refuse 0 as a valid value, in that case hal can spin/sleep for a while until we get
a better value. Alternative is to reread the max value before get/setting brightness.

I can make a patch based on what people think is best. However, it turns out my powerbooks
harddrive controller may soon completely start working (I get 20 min's out of it max, as of today), so not sure if I manage to actually test it.

The second problem may have been fixed already (looking at git) for my specific case. 
But it may still be valid for some of the shell scripts used by hal. 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.

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.


Danny