[patch] some fixes for is_mounted detection

Sjoerd Simons sjoerd at luon.net
Sun Jul 4 12:01:48 PDT 2004


On Sun, Jul 04, 2004 at 08:09:23PM +0200, David Zeuthen wrote:
> On Mon, 2004-06-28 at 22:37 +0200, Sjoerd Simons wrote:
> 
> >  the number of num_mount_points is reset at the start of the function,
> >  while it could still decide not to reread the mtab. Causing the
> >  mount_points array to be emptied every time something in /etc changed..
> > 
> 
> But we don't do anything if we can't read the file or decide not to; the
> mount_points array is only applicable within the function
> etc_mtab_process_all_block_devices() and this indeed return FALSE if
> there is nothing to do and we check on this.

Then i probably misunderstood what was the intention of the function a little.
I guess it turned up to be a problem, because i had modified some other stuff.
But i still think it's strange to throw away good information ;).

> >   Second at the end of block_class_pre_process both detect_media and
> >   etc_mtab_process_all_block_devices are called, but these only work on
> >   devices in the gdl and at that time the device is still in the tdl. So
> >   they're basically nops there. To solve this i've adjusted the
> >   ClassDeviceHandler stuff to also call the post_merge function. And let
> >   the one for block devices call detect_media and
> >   etc_mtab_process_all_block_devices..
> 
> This is a good point but it seems wrong to use post_merge for this.
> Perhaps we should have an added_to_gdl method on both ClassDeviceHandler
> and BusDeviceHandler that is called when it's in the GDL?

It depends on what exactly is ment by merge, if it's merging new info into a
device a added_to_gdl is nicer. If it's merging new information (either
properties updates of a new device) into the GDL, then using post_merge is fine.

Both meanings sound fine to me and the last one was the least work, so i choose
that when writing the patch :)

  Sjoerd
-- 
Immortality -- a fate worse than death.
		-- Edgar A. Shoaff

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list