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?
> 
> Sure! Please create then an issue.


OK, here's the issue: https://github.com/ilbers/isar/issues/38


Besten Gru�,
   Christian

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