[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