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

[Danny Kukawka]

On Tuesday 09 January 2007 21:31, Sergey Lapin wrote:
> > Not sure if this is currently the case, but in the past you could copy a
> > new fdi-file to the related directory, (re)plug the related hardware and
> > the fdi-file was read in (IIRC).
> >
> > The point is: if my both points not work, it's maybe acceptable for a
> > embedded device, but not for a normal desktop/laptop or a server (where
> > HAL start need several minutes or more as in the past).
>
> It runs in less that 3 seconds on my current laptop. And surely not
> slower that original solution. You could test for yourself. You surely
> don't need minutes for that. 

I didn't say you need minutes to run create the cache file, but for start of 
HAL on machines with many (e.g. several 1000 harddisks) devices. 

> At least this patch won't make hal startup 
> slower on servers/desktops. And, also, yes, you need to restart hal in
> current git to re-read configs, and I don't see where it is bad.

This is bad because e.g. of the above issues and if you only want to add a new 
fdi-rule for a special device you don't want to restart hal on a machine 
where this need several minutes. For this case you should only need to attach 
the device or e.g. rmmod/modprobe the device module. 

You should remember there are machines (e.g. big s390/s390x or ia64 machines) 
with more devices than in a embedded device as n770 or on a normal desktop 
with max. ~150 devices. We have on SUSE e.g. requests to support machines 
with > 8000 scsi channels, but you get already problems with machines with 
have more than 1000 devices. 

> In either case, notification mechanism could be provided for hald to
> reload cache when hald-cache finish run, which could remove need for
> restarting hald separately. This patch is proposed improvement, and it
> provides no regression with current git behaveour.

The current git behavior is IMO already a regression compared to former 
behavior where all fdi-files get checked (yes this was slower, but the data 
was allways up-to-date) if a new device get added.

The point is: I don't want to start the cache creation by hand, validate the 
start of the process and the return value and check if the file was really 
created. This should be handled inside/by HAL and not from the outside (which 
not mean you can trigger this manually). And what I also not want is that I 
have to care of if the current cache is actual as the fdi-files are.

Danny