[Commotion-dev] Single su (aka Shell Fork)

Hans-Christoph Steiner hans at guardianproject.info
Tue Sep 4 16:13:42 UTC 2012 


On 09/04/2012 10:53 AM, Will Hawkins wrote:
> Hello Hans!
> 
> On 09/03/2012 10:23 PM, Hans-Christoph Steiner wrote:
>>
>> I tried using
>> https://github.com/opentechinstitute/shell-fork
>>
>> And it doesn't build because the tests fail because it can't find
>> org.junit.*.  That's because there are hard-coded, absolute paths in
>> shell-fork/build.xml that will only work on your machine:
>>
>> <property name="junitJarFile"
>> value="/home/hawkinsw/code/junit/junit-4.10.jar"/>
>> <property name="androidJarFilePath"
>> value="/home/hawkinsw/android-sdk-linux/platforms/android-16/"/>
> 
> The androidJarFilePath in build.xml is there as a default only. Its
> value gets set to the developer's host-specific path in the Makefile.
> 
>>
>> The Android SDK seems to include JUnit, but I couldn't find the jar or
>> any classes.  So I just pointed to the standard Debian/Ubuntu/Mint
>> install location for this jar, /usr/share/java/junit4.jar, and added
>> 'junit4' to the list of required packages.  Perhaps there is a better
>> way to handle this.
> 
> I tried to make the build.xml as configurable as possible, even with
> those hard-coded paths. I found it odd that junit is not a commonly
> installed library so I went out and got one from their repository for
> testing. I thought that I had made the build.xml so that junit was not
> required for a normal build.
> 
> In any event, thanks for correcting that for me!

In any case, it would be nice if the build didn't fail if junit4.jar is
missing.  As for default file locations, I try to use something that is
as common as possible, like the path from the related Debian/Ubuntu/Mint
package.  Using dev-specific paths for defaults means guaranteed failure
for everyone else ;)

.hc

>> I also renamed things to match up with filenames:
>>
>> - submodule is now called external/shell-fork, same as the repo
>> - Makefile targets and vars are called 'fork' and 'shell-jar'
>>
>> I'm a bit obsessed with consistency, and I find these kinds of things
>> make the code more self-documenting.  It works on my phone, so I
>> committed and pushed everything.  I think it makes sense for you to
>> commit directly going forward.
> 
> Thanks for making those changes. I hope that what I added to the
> external/Makefile was relatively consistent with your prior work. I was
> really impressed with the number of configuration options available in
> that Makefile and its ability to generate reasonable defaults!
> 
>>
>> We could also do a code review before pushing to the official repo.
>> We've been doing that on some of our projects and I think its workign
>> nicely.  Basically, we each work out of our own developer repos and push
>> them to a public per-developer repo to make the review process easier.
>> Then we review each others' commits before they pushed to the official repo.
> 
> I think this sounds great. Now that we have this initial integration
> done, we can use this process going forward as I modify the fork code to
> be stdio-driven.
> 
> Thanks Hans!
> Will
> 
>>
>> .hc
>>
>> On 08/30/2012 03:42 PM, Will Hawkins wrote:
>>> Thanks for your reply, Hans.
>>>
>>> Here is a repackage of those patches w/out the commented out wifi lock
>>> code. I tend to agree that removing code outright is the best,
>>> especially when everything is under revision control. When I look back
>>> at blocks of code that is commented out I always wonder if I left it
>>> there with intent to put it back in later! It's so much clearer when
>>> it's just gone.
>>>
>>> Let me know if you need other modifications to these patches.
>>>
>>> Will
>>>
>>> On 08/30/2012 11:44 AM, Hans-Christoph Steiner wrote:
>>>>
>>>> I think your approach has a lot of potential for streamlining the
>>>> handling of root in Android apps.  I'm still trying to wrap my head
>>>> around it, so that's where a lot of my questions come from.  Then I'm a
>>>> bit dogmatic when it comes to "as simple as possible".
>>>>
>>>> Will, could you reissue your patches without the API change and removal
>>>> of the wifi lock?  Or if the wifi lock is an issue, that should probably
>>>> be handled separately.  Also as a stylistic thing, I think there is no
>>>> need to leave in commented out code, since that code will always be in
>>>> the git history.  But others disagree on that one.
>>>>
>>>> .hc
>>>>
>>>> On 08/30/2012 11:27 AM, Will Hawkins wrote:
>>>>> Hey Hans,
>>>>>
>>>>> Josh, Andrew and I discussed this further offline. We talked about
>>>>> making this change to interact with fork via stdio in a future release.
>>>>>
>>>>> I talked about the rationale of using TCP/IP and session keys in the
>>>>> first place (debugging convenience, asynchronicity of issuing
>>>>> control/input commands) and the reason why it's not a big deal to switch
>>>>> over. That said, staying with TCP/IP at this point seems like a good
>>>>> idea to us so that we can have a fixed debugging target while fork is
>>>>> integrated with MeshTether. As far as I can tell, the change to this
>>>>> model of interaction between user and fork would not significantly
>>>>> change the API.
>>>>>
>>>>> I am really glad that you provided this level of feedback. You and other
>>>>> Guardians (n8fr8) are very talented developers and I look forward to
>>>>> incorporating your bug reports and feedback.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> On 08/29/2012 05:38 PM, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>>
>>>>>> Would it be possible to start 'fork' in a Java Thread, then interact
>>>>>> with it using stdin/stdout using StreamThread or something like that?  I
>>>>>> would be nice to not have to use TCP/IP and a session key.
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> On 08/28/2012 05:24 PM, Will Hawkins wrote:
>>>>>>> Hey Hans,
>>>>>>>
>>>>>>> Replies inline.
>>>>>>>
>>>>>>> On 08/28/2012 03:36 PM, Hans-Christoph Steiner wrote:
>>>>>>>>
>>>>>>>> Wow, it turned into quite a project.  It might take me a bit of time to
>>>>>>>> wrap my head around it. A couple of questions:
>>>>>>>>
>>>>>>>> - Is this for use in other projects besides MeshTether?
>>>>>>>
>>>>>>> Could be. :-)
>>>>>>
>>>>>>>> - does fork require android-16?  That will eliminate the majority of
>>>>>>>> deployed devices. This is set in 0001-Add-fork.patch
>>>>>>>
>>>>>>> Does not require it, as far as I know. I only put in 16 as the default
>>>>>>> because it's the SDK platform that I have installed on my machine. The
>>>>>>> gist of what's going on there is this:
>>>>>>>
>>>>>>> The MeshTether app wants to be notified using an Android Handler object.
>>>>>>> To include the ability for the fork Java API to include this
>>>>>>> functionality and build properly, it has to "link" against android.jar.
>>>>>>> (At least that's the way I understand it.) So, as a default I used what
>>>>>>> I had defined on my system and that was 16. The Android Handler has been
>>>>>>> in the API since version 1
>>>>>>> (http://developer.android.com/reference/android/os/Handler.html) so it
>>>>>>> should work on any platform.
>>>>>>>
>>>>>>> I hope I made that clearer rather than, well, vaguer, if that's even a word.
>>>>>>>
>>>>>>>>
>>>>>>>> - Does fork not work with the wifiLock?  It was commented out in
>>>>>>>> 0003-MeshService...patch
>>>>>>>
>>>>>>> That was only commented out because it does not work on the specific
>>>>>>> device that I am using for testing. Sorry for allowing that to slip through.
>>>>>>>
>>>>>>> Please reach out with other questions. I am interested in your feedback,
>>>>>>> as always!
>>>>>>>
>>>>>>> Will
>>>>>>>
>>>>>>>>
>>>>>>>> .hc
>>>>>>>>
>>>>>>>> On 08/27/2012 04:10 PM, Will Hawkins wrote:
>>>>>>>>> Hello everyone!
>>>>>>>>>
>>>>>>>>> The much-talked-about single SU functionality is ready to deploy. Most
>>>>>>>>> of the functionality works through a daemon known as fork. fork is a
>>>>>>>>> shell that allows "the user to remotely start a shell, manage jobs, and
>>>>>>>>> give input and take output from those jobs". For more information about
>>>>>>>>> fork, please refer to the project README file available at
>>>>>>>>> https://github.com/opentechinstitute/shell-fork.
>>>>>>>>>
>>>>>>>>> fork has a Java API that is used to incorporate it into the MeshTether
>>>>>>>>> application. The Java API has JavaDoc to explain its usage. To "make"
>>>>>>>>> the JavaDoc, use the ant target javadoc, as in
>>>>>>>>> $ ant javadoc
>>>>>>>>> The resulting files will be in the bin/ directory of the source code tree.
>>>>>>>>>
>>>>>>>>> Attached to this email are the patches to the MeshTether application
>>>>>>>>> that integrate fork. The patches include changes to Java source code and
>>>>>>>>> Makefiles.
>>>>>>>>>
>>>>>>>>> In order for these patches to work, you must first incorporate
>>>>>>>>> shell-fork (git://github.com/opentechinstitute/shell-fork.git) as a
>>>>>>>>> submodule in the external/fork path.
>>>>>>>>>
>>>>>>>>> I'm sure that there are parts of the integration that I am forgetting to
>>>>>>>>> mention. Please send email and we can hash things out.
>>>>>>>>>
>>>>>>>>> :-)
>>>>>>>>> Will
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Commotion-dev mailing list
>>>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Commotion-dev mailing list
>>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Commotion-dev mailing list
>>>>>>> Commotion-dev at lists.chambana.net
>>>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Commotion-dev mailing list
>>>>>> Commotion-dev at lists.chambana.net
>>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>>
>>>>> _______________________________________________
>>>>> Commotion-dev mailing list
>>>>> Commotion-dev at lists.chambana.net
>>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>

More information about the Commotion-dev mailing list