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

[Alexander Smirnov <asmirnov@ilbers.de>]

On 11/14/2017 10:36 AM, Christian Storm wrote:
> 
>>>> [...]
>>>> 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.

Alex