> On 27. May 2023, at 18:56, Robert Elz <kre%munnari.OZ.AU@localhost> wrote: > > I'm dual-posting this to tech-kern and tech-userlevel, as while it is > a userlevel issue, it could have kernel implications. Please respect > the Reply-To and send replies only to tech-userlevel > > You may have noticed that a recent change (mine) to the pathadj() > function (which converts an abritrary path name to its canonical form). > That function is not permitted to fail, but could. Now instead of > failing, and returning (potential) nonsense, it exits if it cannot > do what it is required to do (usually it can). In practice this > affects nothing real. > > However, it affects some uses of rump - which sets up a "block device" > in a way that its name cannot be canonicalised. It was relying upon > the way that pathadj() happens to work (based upon how realpath(3) works) > to make things function - pathadj() was issuing an error message, which > some rump using ATF tests were simply ignoring (deliberately). > > Yesterday, I was trying to find a way to make this all work - unsuccessfully. The magic needed here is "blanket" from RUMPHIJACK(3) ... The "real" device name would be "/rump/dk" but unfortunately the path is also present in the argument to the mount call where the prefix is not stripped. Using "blanket=/dk" makes both the realpath() and the mount() get hijacked without having to modify the device path. The attached diff should fix the tests. -- J. Hannken-Illjes - hannken%mailbox.org@localhost
Attachment:
001_use_blanket.diff
Description: Binary data
Attachment:
signature.asc
Description: Message signed with OpenPGP