Dear Dharam,
Thanks for your quick reply and your suggestion has shed a light on my
understanding of the porting the gRPC.
I think the compiler I'm using now is a problem. At the beginning, I
follow the steps defined in README file in gRPC to cross-compile the
project, I found the step is to build the whole project on the Host as
there are some
Dharam Kumar於 2019年9月12日星期四 UTC-7上午5時05分23秒寫道：
>
> Sorry, I didn't get your name :) . But here is my take on your questions -
>
> 1. I was using gcc compiler - so I didn't see any problem with lack of
> c++/c11 library features. Most compilers support features like 'atomic' -
> check if your compiler offers it or not.
> Overall, I think it is good to have, if not essential, to have c++/c11
> support in your compiler. It will save a lot of hard-work for you.
> For example - atomic operation can be emulated in software if your
> compiler does not support by default - but that's additional amount of
> work and it will make the system slower.
>
> 2. I think ThreadX does provide a thin posix implementation(check
> their sample apps/examples etc). Having said that, you may not have to do
> the same. You can always add 'ThreadX implementation'
> to what all grpc OS(posix) interface requires. For example - Queue,
> Threads, semaphores, mutexes, most of basic constructs are already
> available in ThreadX.
>
> 3. No, grpc may require some of these features. So, you've to review
> what you can implement and what you have to disable.
> For example - if GPR_LINUX_ENV is all about setting
> environment(key-value pair), setenv(...), getenv(...) from a linux-host
> perspective. Think of how you can achieve the same
> on your system. See if you can implement and fulfill these API
> requirements on your system. If you'are able to do that, you don't have to
> disable GPR_LINUX_ENV - as a result - all the code/test-apps/examples etc
> will continue to work. Alternative is to come with your own,
> GPR_THREADX_ENV flag and replace it with GPR_LINUX_ENV across the library
> -
> but that might be more intrusive and you may miss things.
>
> Idea is to really see what gets you closer to a working piece of grpc
> library. Like most of porting exercises - it is always good to have a new
> implementation of the interface
> rather than having a new interface itself.
>
>
>
>
> ------------------------------
> *From:* [email protected] <javascript:> <[email protected]
> <javascript:>> on behalf of [email protected] <javascript:> <[email protected]
> <javascript:>>
> *Sent:* Thursday, September 12, 2019 3:36 PM
> *To:* grpc.io <[email protected] <javascript:>>
> *Subject:* Re: [grpc-io] Re: gRPC for embedded systems( for example -
> RTOS like ThreadX, FreeRTOS etc. )
>
> Hello Dharam,
> I'm lucky to see your mail when I'm planning to put grpc to embedded
> device running ThreadX.
> But it's not easy for me since grpc does not provide any options for
> embedded device running RTOS.
>
> I have following questions and I'm looking forward to your reply.
>
> 1. The compiler I'm using is DS-5 ARM compiler 6.02 armclang which
> has unsupported features such as -stdlib=libstdc++, and use of C11 library
> feature.
> so there're many compiling issues like atomic is not supported, no type
> named 'memory_order' in namespace 'std'.
> Did you see these compiling issue like these? what compiler are you
> using for compiling grpc? If atomic is not supported, is it possible to
> compile and run gprc?
>
> 2. As POSIX APIs are not supported in ThreadX. So these posix-APIs
> need to be implemented by my own?
>
> 3. When adding options for THREADX in port_platform.h, I disable many
> features such as GPR_LINUX_LOG, GPR_SUPPORT_CHANNEL_FROM_FD, GPR_LINUX_ENV
> and GPR_POSIX_TMPFILE
> But I'm not sure if grpc can work properly as these features are
> disabled. Any suggestions?
>
> Thanks!
>
> Dharam Kumar於 2019年8月21日星期三 UTC-7上午3時22分48秒寫道：
>
> Hello Jaehong,
> I've been able to put grpc framework on wiced rtos APIs
> <https://www.cypress.com/products/wiced-software>. Basically, Wiced SDK
> from Cypress provides abstracted RTOS/Networking APIs which is underneath
> implemented by different rtos/network stacks. For example -
> Expresslogic's ThreadX/NetX, FreeRTOS/lwip etc. I was able to get threads
> running, start grpc core service, create grpc endpoints(tcp) etc...
>
> Please note that grpc library does not support embedded TLS stacks like
> mbed-tls(from ARM). Also, default grpc transports module(chttp2?)might be
> too heavy for your embedded platform. So, you may have to work on these
> aspect. So be remindful of how "embedded" you can go. For example - it
> probably won't work on a board/platform with 256KB of RAM.
>
> In nutshell, putting grpc framework is totally possible.
> ...@Nicolas Noble - I'm not sure about the grpc being intertwined with
> posix part - as i recollect there are pretty good grpc abstractions for
> different platforms(windows, unix, posix etc.) - i just built on that and
> was able to get the grpc core up and running.
>
> Br,
> Dharam
>
> ------------------------------
> *From:* [email protected] <[email protected]> on behalf of
> Nicolas Noble <[email protected]>
> *Sent:* Wednesday, August 21, 2019 12:31 AM
> *To:* jaehong park <[email protected]>
> *Cc:* grpc.io <[email protected]>
> *Subject:* Re: [grpc-io] Re: gRPC for embedded systems( for example -
> RTOS like ThreadX, FreeRTOS etc. )
>
> We have no plans for that, and the current codebase is way too intertwined
> with posix to ever work on FreeRTOS / lwip. A full third party
> implementation of grpc would be needed for that at this point.
>
> On Tue, Aug 20, 2019 at 10:23 AM jaehong park <[email protected]> wrote:
>
> Hello Dharam,
>
> I'm having a similar project like below question.
> (III.Any effort in community in bringing gRPC for embedded devices(for
> RTOSes) ? )
> Do you have any progress this issue?
>
> Could you let me know where I can find the answer for this?
>
> Thanks,
> Jaehong
>
>
>
> On Tuesday, January 23, 2018 at 9:39:07 PM UTC-8, [email protected]
> wrote:
>
>
> Hello folks,
> I'm working on a project where we are planning to create a Google
> Assistant service instance on embedded/deeply embedded devices( non-linux,
> ARM processors running RTOS like ThreadX, FreeRTOS etc. )
> Our system has support for building executables for c/c++ etc. but it is
> not same as linux( for example - no posix availability ).
> Of course, like RTOSes these days, we have wrappers for providing
> OS/Networking functionality for applications/libraries to use.
>
> My questions are:
>
> i. How fit gRPC is for embedded devices? I can see abstraction for
> different platforms in "port_platform.h" file used to build grpc-core with
> options given in the file.
> My first thought is it should be doable if I adapt port_platform.h
> and build grpc-core with the capabilities provided by our system.
>
> ii. How deep gRPC's love is for posix? If any platform/devices does not
> provide any posix-like high level APIs, will gRPC still work as expected?
> How straight-forward such a task is going to be?
>
> iii. Any effort in community in bringing gRPC for embedded devices(for
> RTOSes) ? Would not it be great to have a tiny(and limited) gRPC library
> which can be
> easily integrated to embedded devices ? And such a thing supported by
> gRPC community/authors ?
>
> I understand that I can get most of the answers from reading the code
> itself(which I'm doing btw).
> But it would be nice to know insights/perspective of gRPC authors and
> community folks who understands gRPC better than me.
>
> Open for suggestions/feedback.
>
> Best regards,
> Dharam
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/5a72e682-031f-415b-830f-7818810f434f%40googlegroups.com
>
> <https://groups.google.com/d/msgid/grpc-io/5a72e682-031f-415b-830f-7818810f434f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/grpc-io/A0PlDMi2an8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CAEvr0PEr7TM5m3JUtP04Jgc3tZj6zSx%2BmfRdGJNh5hwsB0HH6Q%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/grpc-io/CAEvr0PEr7TM5m3JUtP04Jgc3tZj6zSx%2BmfRdGJNh5hwsB0HH6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> This message and any attachments may contain confidential information from
> Cypress or its subsidiaries. If it has been received in error, please
> advise the sender and immediately delete this message.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/grpc-io/A0PlDMi2an8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected] <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/4d301f1c-04fd-43a2-9e1c-3061329a0a5b%40googlegroups.com
>
> <https://groups.google.com/d/msgid/grpc-io/4d301f1c-04fd-43a2-9e1c-3061329a0a5b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
> This message and any attachments may contain confidential information from
> Cypress or its subsidiaries. If it has been received in error, please
> advise the sender and immediately delete this message.
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/341677b4-7152-4906-a5c9-2ca1ba92f2a4%40googlegroups.com.
