-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate libparted, in-memory partition management, & advanced partitioning #24
Conversation
@mmstick This is looking pretty good to me right now. Unfortunately I will not have enough time to test this in depth, due to going to CES tomorrow and Friday. When I get back I will go through the changes made to distinst and libparted in more depth. |
@jackpot51 That's fine! I'll continue working on this in the meantime. Good luck at CES! |
Thanks! |
It's possible for users to unplug and swap hard drives after obtaining partition information. Therefore, to prevent issues from occuring as a result of that, disks will now contain serial number information which can be used as a unique identifier when commiting partition changes to disks.
Defines the API for performing disk operations and partially, implements the methods to do so. However, as these are simply stubs, none of these are wired up yet, so there's much dead code warnings at the moment.
Another step towards integration of libparted. The functionality theoretically works, but it has not yet been integrated into the library, and so it is currently dead/dormant code.
This adds the following methods on `Disk`: - move_partition - resize_partition - format_partition - remove_partition - diff Tests have been created to verify that the new features work, and more tests are coming soon.
Cargo.toml
Outdated
@@ -6,16 +6,17 @@ authors = ["Jeremy Soller <jackpot51@gmail.com>"] | |||
build = "build.rs" | |||
|
|||
[lib] | |||
name = "distinst" | |||
crate-type = ["lib", "dylib"] | |||
crate-type = ["dylib"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why should it be only dylib?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Causes a build failure otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems the fix for this particular issue is to ensure that each lib crate type is compiled on independent runs. They can't be built together:
cargo rustc --lib --release -- --crate-type=lib;
cargo rustc --lib --release -- --crate-type=dylib;
cargo build --bin distinst --release;
Now, in addition to being used for metadata, the new partitioning logic is now being used within the library to partition disks. The new code should be doing exactly what the old code was doing before
The mklabel function has been made a Disk method so that it can be updated after the action is performed, and the tables are wiped clean
Hopefully, everything should be working pretty well now.
If there's a compile error, you'll get an unhelpful error message about unparsed tokens. This will allow you to build the library and receive error messages if you build the bin or lib. This also will ensure that the dylib-related stuff doesn't execute when building just the bin/lib.
The hard coded partitioning logic has been removed from the library and shifted towards the binary. Library users should therefore now be able to support custom partition schemes of their choosing.
Closes #12
Closes #19
libparted
Partitioning will depend upon the libparted library for obtaining information about disks and their partitions, as well as the creation and manipulation these partitions. libparted is written in C, with a very object-oriented and error-prone manner. The libparted Rust bindings, and consequently distinst itself, will offer a simpler, safer interface to the functions provided by libparted.
In-Memory Partition Management
There shall be an in-memory partition management system that the user will interface with to make changes and be notified of incompatible changes, and from which disk operations will be constructed from using a diff of the original partition scheme and the partition scheme to deploy.
Formatting
As partitions are created and manipulated, the
mkfs
command will be used to format the unformatted partitions, or to reformat existing partitions. In addition, theudevadm
command will be used to get the serial model of disks being manipulated, to ensure that we are writing changes to the correct disk in the event that the user changes the location of the disk mid-install.Advanced Partitioning
Users of the library should now be able to specify their own partition configurations. If the configuration is deemed valid (has the right partitions set based on the bootloader), then the changes specified will be committed to the disk in the partitioning step.
Current Progress
mkfs
to format newly-created partitionsmkfs
routines for all possible file system types.