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

Will Hawkins hawkinsw at opentechinstitute.org
Tue Sep 4 14:53:06 UTC 2012 

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!

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

More information about the Commotion-dev mailing list