fork() types

[npmccallum]

I'm working on a KVM library and I find myself reimplementing most of the types from this crate. I can't use this crate, however, because of your (legitimate) need for asm!(). Would this project consider merging a patch that splits this crate into two halves: one containing raw types (such as RFlags) and the other containing implementations for things like reading and writing the registers?

[phil-opp]

Is only asm!() the problem or all unstable features? Maybe we can support your use case through (opt-out) cargo features? I'm also open to splitting the crate, depending on the organizational effort (the crate should stay maintainable).

[npmccallum]

It is all unstable features.

[phil-opp]

Ok, then a nightly/stable split might make more sense than a raw type/accessing registers split. For example, the InterruptDesriptorTable struct uses the unstable x86-interrupt ABI.

To implement this split, we could add a cargo feature named nightly that is enabled by default. Then we could gate all uses of unstable features on this nightly feature. This way we can compile a part of the library on stable by disabling the feature.

[npmccallum]

I'm still not sure this really accomplishes what I would want. The problem is that this crate is a mix of two things: x86_64 types and x86_64 instructions. In the case of a hypervisor, we only need the types. Likewise, the instructions depend on the types. But I don't really want the hypervisor to depend on the instructions.

[phil-opp]

Good point. I guess splitting off a "x86_64_types" crate might be the best solution then.

Which types do you propose to move out?

[npmccallum]

Good question. Definitely *Flags.

I'd also like all of the tables. But that brings up an interesting point: the contents of your table structs are private. That would probably have to change.

I also like the *Addr types. We already have a parallel to this. I wonder if we can merge them. In particular, we have implementations that allow things like Deref and lifetime/mutability safety. So maybe we could collaborate on an improved approach here.

[npmccallum]

*Addr brings up another interesting point because they may not be architecture specific. Or rather, they could be generalized for multiple architectures.

[phil-opp]

Sounds good!

I would be more than happy to collaborate with you! How about we start by creating a x86_64_types repository under the rust-osdev organization where we both have push access?

[npmccallum]

Yeah, that sounds great. We can start by just moving existing types and go from there.

[phil-opp]

*Addr brings up another interesting point because they may not be architecture specific. Or rather, they could be generalized for multiple architectures.

In principle yes, but I would prefer to introduce a new type for that. The reason is that we use *Addr in some x86_64 specific types that wouldn't make sense with a host specific address type.

Yeah, that sounds great. We can start by just moving existing types and go from there.

Great! I created the repository at https://github.com/rust-osdev/x86_64_types. I invited you to the organization and gave you admin access to the repo. I also published a initial version to crates.io to claim the name. You should have publish access too.

[phil-opp]

I put in a MIT/Apache2 license and created some branch protection rules for master (require pull requests and at least 1 approving review), I hope that's fine with you.

[npmccallum]

License is perfect. I'm going to start filing pull requests for moving the types.

[phil-opp]

Great!

[npmccallum]

How stabilized is this crate currently? Here's a thought...

Once we move out all the register types, it might make sense to implement read/write of those registers as a trait. We could probably even macroize it.

Also, for RFlags, it might be nice to implement some helper methods for getting/settings the iopl.

[phil-opp]

We're still in the 0.x.y version range, so we can always release a new breaking version. However, I still want to avoid breaking changes when possible.

Adding a trait sounds good in principle. I'm not sure what macros you have in mind, but I'm always a bit reluctant to adding user-facing macros because they are new thing that users of the library have to learn.

Also, for RFlags, it might be nice to implement some helper methods for getting/settings the iopl.

Sure, adding functionality is fine with me. I didn't looked into the details of RFLAGS right now, but if it works it should be fine to add.