[PATCH][RFC] cache generation + separate FDI parser process

Rob Taylor rob.taylor at collabora.co.uk
Tue Jan 9 09:13:10 PST 2007


Danny Kukawka wrote:
> On Tuesday 09 January 2007 14:20, Sergey Lapin wrote:
>> Hi!
>>
>> Attached is a patch which provides these improvements:
>>
>> - Separates XML parsing from main running process thus reducing memory
>> fragmentation and consumption.
>> - maintains binary cache which is mmapped for reading thus not using
>> heap for that, so it uses mapped memory which is freed on demand which
>> is good for small-memory embedded devices.
>> - makes hald smaller due to fact that bunch of rarely used code is out
>> in separate process.
>>
>> so you get /usr/sbin/hald-cache which generates cache at /var/run/hald
>> (for example) which is then used by hald, so it must exist prior to
>> running hald.
> 
> I'm not a fan of an extra process which need to be run before starting hald. 
> There should be a atomatic way (inside hal) to do this without start this 
> tool (and monitor it) in a rc-file.

I agree that there should be an automatic cache consistency check if
this is used.

> This change mean I can't add a new fdi-file and attach my new hardware without 
> restart HAL or/and hald-cache? No good idea on a normal system (and not a 
> embedded device with known number of devices). And if I need to validate and 
> read all files with each (re)start or change I can't see a significant 
> advantage on nomal systems compared to a in HAL solution(or something like a 
> addon/callout).

Isn't it that case that you currently need to restart hal to reload
fdis? (di_init_rules is only called when no fdi's have been parsed and
cached yet)


Thanks,
Rob Taylor



More information about the hal mailing list