Re: [PATCH] isar-image-base: fix some dangling mounts

[Christian Storm <christian.storm@siemens.com>]

> >> [...]
> >> Here I see that you insert quite similar patterns across the Isar code,
> >> would it be better to have one global clean up function like?
> >>
> >> do_isar_mount_cleanup () {
> >>       if [ -d "${WORKDIR}/mnt" ]; then
> >>           # umount and remove
> >>       fi
> >>
> >>       if [ -d "${WORKDIR}/rootfs/proc" ]; then
> >>           # umount and remove
> >>       fi
> >>
> >>       if [ -d "${BUILDCHROOT_DIR}/proc" ]; then
> >>           # umount and remove
> >>       fi
> >>
> >>       etc...
> >> }
> >>
> >> This approach will significantly simplify maintenance of clean up traps
> >> and adding of new possible mounts to Isar. What do you think?
> > 
> > I'd say it depends :)
> > It breaks if you rely on keeping something mounted while executing a
> > child script that does unmount everything, following your proposal. If
> > we can make sure that such a situation never occurs, we may consolidate
> > this. For now, it's rather local just undoing the mounts done in the
> > scope of the script.
> > So, in the end, I think it's a matter of taste and contracts between the
> > different parts of Isar.
> > 
> 
> Ok.
> 
> > What one may consider to "de-duplicate" is a stack of mounted directories
> > being pushed to and unmounted on script exit. So, something like
> >    push_umount ${IMAGE_ROOTFS}/proc
> > and then the EXIT trap enumerates all those entries, unmounting them.
> > The same has to be done for removing the directories, if applicable.
> 
> This sounds reasonable, will try to implement this?
> 
> BTW: for me it's not the point for me to block current patch, it'd be 
> very helpful to have it in the tree now.

OK, then let's merge it and create a github issue to refactor it later
as I do have more mount-related stuff in my queue :)
Once all mount-related patches are merged, we do have a clearer picture
and can account for all this at once in terms of a discussion and a
proper concept on the github issue. So, I propose we merge this and I'll
send the other patches out once ready and then we do a refactoring with
discussion on the right way to do it on the github issue. My proposal
with the stack may serve as a starting point for discussion on the
github issue.

What do you think? Would that be OK for you?



Besten Gru�,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Otto-Hahn-Ring 6, 81739 M�nchen, Germany