Page MenuHomeFreeBSD

Check to see if the kernel has cd9660 before attempting to mount created images
ClosedPublic

Authored by brooks on Apr 26 2017, 11:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 23 2024, 4:34 PM
Unknown Object (File)
Feb 23 2024, 4:34 PM
Unknown Object (File)
Feb 23 2024, 4:34 PM
Unknown Object (File)
Feb 23 2024, 4:34 PM
Unknown Object (File)
Feb 23 2024, 4:20 PM
Unknown Object (File)
Dec 25 2023, 9:37 AM
Unknown Object (File)
Dec 20 2023, 5:12 AM
Unknown Object (File)
Dec 13 2023, 3:55 AM
Subscribers

Details

Summary

This extends the set in r316028 to allow all tests to pass or be skipped
on a system without cd9660 support.

Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
MFC After: 1 week

Test Plan

tested on a mips64 qemu system without cd9660 support

Diff Detail

Lint
Lint Warnings
SeverityLocationCodeMessage
Warningusr.sbin/makefs/tests/makefs_cd9660_tests.sh:CHMOD1Invalid Executable
Unit
No Test Coverage
Build Status
Buildable 8964
Build 9357: arc lint + arc unit

Event Timeline

Is this solving an issue seen on CheriBSD, or a hypothetical issue?

In D10516#217955, @ngie wrote:

Is this solving an issue seen on CheriBSD, or a hypothetical issue?

Real in that the MALTA64 kernel doesn't contain a cd9660. r316028 seems to have only covered half the cases that require mounting the created filesystem.

I'm ok with all of the changes but to :o_flag_isolevel_3 (it would eliminate potential coverage today)

usr.sbin/makefs/tests/makefs_cd9660_tests.sh
261

This isn't necessary, yet, but it will be in the future. Maybe this should be moved down?

This revision is now accepted and ready to land.Apr 28 2017, 6:34 AM

FWIW, I'm not convinced mounting the file systems is the best option. We should probably mount one of them, but extracting the files with tar would be more portable.

usr.sbin/makefs/tests/makefs_cd9660_tests.sh
261

I don't see any reason not to add it since the mount_image call requires it. Otherwise we add bogus failures to systems where the test will fail as soon as makefs is updated.

After realizing I misunderstood how atf-sh works (atf-check returns immediate failure if it fails, not at script exit), I wonder if check_cd9660_support should be rolled into mount_image. Then we'll do unvalidated image creation testing even when kernel support is missing.

After realizing I misunderstood how atf-sh works (atf-check returns immediate failure if it fails, not at script exit), I wonder if check_cd9660_support should be rolled into mount_image. Then we'll do unvalidated image creation testing even when kernel support is missing.

Hmm, it can't actually go in mount_image. I'll revise this diff and move all the check_cd9660_support calls down.

brooks edited edge metadata.
  • Go ahead and create the images even if we won't be able to mount them.
This revision now requires review to proceed.Apr 28 2017, 5:11 PM
brooks retitled this revision from Check to see if the kernel has cd9660 before running tests that require it. to Check to see if the kernel has cd9660 before attempting to mount created images.Apr 28 2017, 5:12 PM

I'll open another review to use tar instead of mount_cd9660. I think your input is correct there.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 2 2018, 11:34 PM
This revision was automatically updated to reflect the committed changes.