Bug 9459 - We should add IGNORE as an option for the diskmonitor so that a user can override what the system wants to do
Summary: We should add IGNORE as an option for the diskmonitor so that a user can over...
Status: RESOLVED NOTABUG
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: 2.2
Hardware: x86 Multiple
: Medium enhancement
Target Milestone: 2.2
Assignee: brian avery
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-04-13 20:14 UTC by brian avery
Modified: 2016-04-14 16:28 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Yes (doc changes required)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description brian avery 2016-04-13 20:14:38 UTC
We currently only allow "ABORT", "STOPTASKS", "WARN" for actions.  This means that even if I know that my mount point is ok, I can't tell the system to leave it alone. We should either allow IGNORE for the action or add a Variable to disable the monitor altogether.

To add IGNORE, all we need to do is :
change bitbake/lib/bb/monitordisk.py - 
   if action not in ("ABORT", "STOPTASKS", "WARN"):
to - 
   if action not in ("ABORT", "STOPTASKS", "WARN", "IGNORE"):

Nicely, all of the action dispatch code checks for keyword matches, but we should probably add an:
   elif action == "IGNORE":
       pass
just to be clear.      

-----
Why this mattered to me:
I'm running on a Docker container inside a VM on MacOSX.  My sstate is in a  bind (effectively) mounted OSX dir which the container can see. bitbake is unhappy with the inode number; but because of the odd driver being used, that number does not reflect reality.
With the explosion of filesystems, I'd prefer to have an override option in case the user does know better.
Comment 1 Richard Purdie 2016-04-14 12:43:59 UTC
Why wouldn't you just not list this in BB_DISKMON_DIRS at all?
Comment 2 Richard Purdie 2016-04-14 15:08:28 UTC
See above question...
Comment 3 brian avery 2016-04-14 16:27:42 UTC
because I didn't see that I could.  My bad.
Comment 4 brian avery 2016-04-14 16:28:40 UTC
Didn't realize how I should have overridden this.