geom_part: add support for SGI disk labels
AcceptedPublic
Actions

Authored by asomers on Fri, Jun 5, 10:34 PM.

Details

Reviewers

imp
jlduran

Summary

It's read-only for now, because the purpose isn't to run FreeBSD on
systems that use this partition scheme, but rather merely to read data
from SGI-formatted disks.

Some of the code is based on util-linux, which is explicitly public
domain.

https://github.com/util-linux/util-linux/blob/41644c216ee1c81cd346df17b95453ff4004c7a6/include/pt-sgi.h

MFC after: 2 weeks
Relnotes: yes
Sponsored by: ConnectWise

Test Plan

manually tested with 3 SGI disk images, and compared against SGI's output. Regression test added.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 73717
Build 70600: arc lint + arc unit

Event Timeline

asomers created this revision.Fri, Jun 5, 10:34 PM

Herald added a subscriber: ziaee. · View Herald TranscriptFri, Jun 5, 10:34 PM

asomers requested review of this revision.Fri, Jun 5, 10:35 PM

Harbormaster completed remote builds in B73717: Diff 179314.Fri, Jun 5, 10:35 PM

Believe it or not, there's a practical reason for this. I wasn't just tinkering around for fun, honestly.

I'll ignore the trend we've had towards retiring older-format support generally...

This revision is now accepted and ready to land.Fri, Jun 5, 10:46 PM

In D57483#1316905, @imp wrote:

I'll ignore the trend we've had towards retiring older-format support generally...

If you have a better idea for how to read such disks, I'm all ears. Out-of-tree kernel modules are tough to maintain. But maybe a cuse device or something? It's a possibility.

In D57483#1316912, @asomers wrote:

In D57483#1316905, @imp wrote:

I'll ignore the trend we've had towards retiring older-format support generally...

If you have a better idea for how to read such disks, I'm all ears. Out-of-tree kernel modules are tough to maintain. But maybe a cuse device or something? It's a possibility.

That's why I'm ignoring it... :) I don't either.

I echo the words of @imp; I don't even have a real way to test it.
Having said that, this is really cool from a retro-computing perspective.
We need a "It's a U**X system, I know this!" GIF.

It occurs to me that this might be a good use case for an out-of-tree kernel driver written in Rust. It's easy to test, it's small, and it's not wanted within the tree.

In D57483#1317295, @asomers wrote:

It occurs to me that this might be a good use case for an out-of-tree kernel driver written in Rust. It's easy to test, it's small, and it's not wanted within the tree.

Yea. There's a fair amount of lift to do this in rust. But being out of tree, you'd have a fair amount of rust api freedom for a time... though that might make it overall a much tougher problem.