[PATCH][RFC] cache generation + separate FDI parser process
Danny Kukawka
danny.kukawka at web.de
Tue Jan 9 13:04:21 PST 2007
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
More information about the hal
mailing list