Page MenuHomeFreeBSD

geom_part: add support for SGI disk labels
AcceptedPublic

Authored by asomers on Fri, Jun 5, 10:34 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jun 8, 9:29 PM
Unknown Object (File)
Sun, Jun 7, 11:13 AM
Unknown Object (File)
Sat, Jun 6, 7:52 AM
Subscribers

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

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#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.

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.