From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6487873763254730752 X-Received: by 10.223.169.144 with SMTP id b16mr1656340wrd.26.1510649986764; Tue, 14 Nov 2017 00:59:46 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.126.201 with SMTP id z192ls1366348wmc.0.gmail; Tue, 14 Nov 2017 00:59:46 -0800 (PST) X-Google-Smtp-Source: AGs4zMbN2vLbmLD/1h3QBtnEskejG/RVXJtLUrCFFRbn7hgQNWrJoyZ4QZ8b6dykh+gElkYwEu1c X-Received: by 10.28.69.24 with SMTP id s24mr1272274wma.31.1510649986429; Tue, 14 Nov 2017 00:59:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510649986; cv=none; d=google.com; s=arc-20160816; b=ucdVdCiqziDy7Gi5sCuXm+gsr+GtBRE8gApcKJ7VJDAF99BYmHnlr0RBGVrc/Z0PiR 3kwtdl1AjKhpQJAuasxs0sq9djW1Rt1QPTFjGHj92fxyo+68f3s/aNgk3A27MO5zpC4r aghZrhUgOmSgc9ZsRQwZKx5y6pnUGu+g0W6CbqFSDOH9juAc64Z3aCMPLE7B3xgleo+9 LMtIAaP/0KAQDuv6in3Oi6EUeh+UWUxYDEtUyHQifM0xr6IU5XiQzBHTXJ4pbyqYEu9d 2t3Tue1+RCSkse5qdBHe5J0W3q9aHCQlDezP1veBXdjsebFG7VHwBTtt6FLyPZ9FbZ2e jYAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:mail-followup-to:message-id :subject:to:from:date:arc-authentication-results; bh=BATOTVlQYzqHx8CsnZiIZWBprr3Y6GrTXPkV4u7x8gs=; b=OepZ/zHXCuB/5y4SdPZJHOky6K5knxoiRMpG9U0pPASmvqzKUj2aZ9o/b9m5eufeF1 6M9gv7LuM/xVaJPsLnfo26o5GTh33Dh5XTHTnxBUuoVPBt/lfKGP2iuogSNqkOwe59dD cUW9d22y6Ij54ohqJcftANnFCJrB0ELylliQWz2rTVJrHWVdqZm831hcau2pSn4miAKH FuMwOKMrfgB1iWhM1VtjCvbf1PJGcl6pRtjO5KtZsQtY5MPSpqMWnlODFty0gzMDFM7h V0ywQZETRl2KhiSI/Tjx19Gdy3AT1GfYyOqPOZjyvVO5ziDIyz5+eJd5XYxUaNGuiuPQ qgCg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id i76si907273wmd.0.2017.11.14.00.59.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 00:59:46 -0800 (PST) Received-SPF: pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id vAE8xjq4007423 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 14 Nov 2017 09:59:46 +0100 Received: from localhost ([139.25.69.251]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTPS id vAE8xjEk031782 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Nov 2017 09:59:45 +0100 Date: Tue, 14 Nov 2017 09:58:36 +0100 From: Christian Storm To: isar-users@googlegroups.com Subject: Re: [PATCH] isar-image-base: fix some dangling mounts Message-ID: <20171114085836.c526zfz4pl7tnvxc@MD1KR9XC.ww002.siemens.net> Mail-Followup-To: isar-users@googlegroups.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2eca276a-955c-acb9-ae0b-a531512647b9@ilbers.de> User-Agent: Mutt/20170113 (1.7.2) X-TUID: 3FulyDke6ftl > >>>> [...] > >>>> 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