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

Mon Sep 3 19:02:04 UTC 2012

Hey Will

I just noticed, the 0001-Add-fork.patch includes a git URL that probably
only you can reach since its an ssh connection using the account
'hawkinsw'.  I'm guessing you meant to use the publically accessible URL:
https://github.com/opentechinstitute/shell-fork.git

.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