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

[Will Hawkins]

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
>