Dear Dharam,
Sorry for my late reply.
Thanks for your quick reply and your suggestion has shed a light on my
understanding of the porting the gRPC:)
About Atomic feature, I switch to ARM compiler 6.6 which can support
<atimic> now.
Normally, for corss-compile the gRPC, I checked the README and some
information on the web:
GRPC_CROSS_COMPILE=true
PROTOBUF_CONFIG_OPTS=--host=arm-linux
--with-protoc=/usr/local/bin/protoc
HAS_PKG_CONFIG=false
The steps for cross-compiling are as follows:
# First, clone and make install of grpc using the native compilers for the
host.
# Also, install protoc (e.g., from a package like apt-get)
# Then clone a fresh grpc for the actual cross-compiled build
# Set the environment variable GRPC_CROSS_COMPILE to true
# Set CC, CXX, LD, LDXX, AR, and STRIP to the cross-compiling binaries
# Also set PROTOBUF_CONFIG_OPTS to indicate cross-compilation to protobuf
(e.g.,
# PROTOBUF_CONFIG_OPTS="--host=arm-linux
--with-protoc=/usr/local/bin/protoc" )
# Set HAS_PKG_CONFIG=false
# To build tests, go to third_party/gflags and follow its ccmake
instructions
# Make sure that you enable building shared libraries and set your prefix to
# something useful like /usr/local/cross
# You will also need to set GRPC_CROSS_LDOPTS and GRPC_CROSS_AROPTS to hold
# additional required arguments for LD and AR
# Then you can do a make from the cross-compiling fresh clone
$make
But the ARM compiler 6.6 I'm using is a windows version, which means most
of the command in gRPC make process is not executable.
Then I try to build gRPC on Linux host first(use the Makefile in gRPC
source code) in order to know:
1. how many libs will be generated
2. the corresponding sources files compiled for the lib.
3. compiling options for each lib.
By adding these source files to my ThreadX compiling system(windows based),
I start to compile them.
I know it's not a easy task to build a gRPC lib for embedded system and it
will take months to make it work.
I'm very happy to know you and your suggestion means a lot to me.
Thank you!
Leon
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/4ea8871b-fa22-48d7-b3f3-1bb029fa03f8%40googlegroups.com.
