Add "target-disk-mode" example system #110
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
samueldr
force-pushed
the
examples/jumpdrive
branch
from
966205c
to
5b10f5a
Compare
samueldr
force-pushed
the
examples/jumpdrive
branch
from
5b10f5a
to
6c396f3
Compare
samueldr
added
the
9. status: WIP
samueldr
force-pushed
the
examples/jumpdrive
branch
from
6c396f3
to
0ae1f65
Compare
|
I have just now tested it by doing an extremely dangerous configuration and sharing the internal storage of What does this mean? The "jumpdrive" example system is verified to work. |
samueldr
removed
the
9. status: WIP
samueldr
commented
Oct 3, 2020
samueldr
force-pushed
the
examples/jumpdrive
branch
from
0ae1f65
to
343edeb
Compare
samueldr
force-pushed
the
examples/jumpdrive
branch
2 times, most recently
from
5187b15
to
b8977bb
Compare
samueldr
commented
Jan 4, 2021
Same as File.symlink, but logged. (Also fixes logging of System.write)
This will be used for quirks that needs to know where to write more configuration.
This only serves to show instructions and reboot/poweroff. In the future, it should be the owner of gadget mode stuff.
This is not ideal. Ideally devices would provide that information, but since for now it's only used by jumpdrive, we're skipping the generalization. Furthermore, I don't really know how to provide that information in a way that is coherent with the rest, for now.
samueldr
force-pushed
the
examples/jumpdrive
branch
from
b8977bb
to
1a79fce
Compare
|
(Tested recent updates with out-of-tree chuwi-hi10prohq64) |
samueldr
removed
the
9. status: WIP
samueldr
changed the title
samueldr
force-pushed
the
examples/jumpdrive
branch
from
278be88
to
b7d1fe8
Compare
samueldr
commented
Jan 4, 2021
There was no need to keep it there. Came from the `examples/hello` GUI task, which in turn I *think* that in the past used a variable interpolation. We don't need any of that.
For "whole disk image" systems, like the Pinephone, this produces much smaller images.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds on top of #96.
This adds an example system taking inspiration from JumpDrive.
The given system, once booted, should present the internal storage of the device to the host computer. Just like a usb flash drive (or jump drive).
There are notes in the added README.
The name, though, comes from the Apple feature.
I say should because I am unable to test it. My Pinephone unit seemingly has a fault making usb gadget mode fail. (Verified not to work with the actual JumpDrive project.)
I tried testing with another mainline device I hoped would do gadget mode, but it seems that
asus-dumocan't do gadget mode. It does try to, but something seems to fail between the host and the device. I haven't been able to confirm whether the gru family of devices, gru scarlet and dumo mainly, should work with gadget mode or not (once adapted).Describe all storage
Right now we hardcode
storage.internal.We probably want to, instead, present a choice in the GUI for which storage to export.
Storage should be described in two ways:
Either of those should only be exported by the device description if it is safe to
ddgarbage onto them. This means that most android-based devices fail this requirement.The UI should collect all of those and present them as a selection, either radio buttons or drop down selection. Most likely radio buttons?
This does mean we need to extract the gadget mode stuff from the init, and produce a proper HAL utility class. It should be possible to edit, start and stop gadget features as desired.
TODO