Discussion of new folder structure for `luci-micro`

[lemmaa]

The work to make luci-micro a standalone solution is in full swing. During the process, there was an opinion about getting luci-micro out of the /compiler folder. It is thought to be a reasonable option for the current CI operation method and for future maintenance.

As the separate code of luci-micro is landing, now seems like a good time to try this.

Initially, the luci was developed for the purpose of just handling IRs, but as it develops, now luci-micro acts as a great independent runtime. Therefore, I think it is not appropriate to put it under the /compiler. It is closer to runtime in nature.

From another point of view, the device class targeted by onert and luci-micro are different. Therefore, I think it might be a good option to manage them separately from each other. It will also be a good choice if we need to configure a suitable build system for the target platform of luci-micro.

If there is a possibility that luci-micro will expand to multiple components rather than just one, we would like to group it into a folder like /compiler or /runtime. If we do, what name would you like? /micro? /lite? what else?

Appreciate your comments and views for all areas of this topic. :)

/cc @BalyshevArtem , @SlavikMIPT , @binarman , @seanshpark

[BalyshevArtem]

I vote for the /lite variant :)

[chunseoklee]

If we do, what name would you like? /micro? /lite? what else?

Then, luci-micro directory(top of licu-micro) will place under final winner directory name ? For example, lite/luci-micro in the case of we choose lite ?

[binarman]

@chunseoklee Do we have some agreements on directory structures?

I thought we could simply move /compiler/luci-micro to /lite (or whatever we choose). MCU interpreter do not have any dependencies from other ONE components (except circle), so I think directory with single subdirectory will look awkward.

This design is chosen because interpreter should be small as possible in order to minimize flash memory consumption, so I don't think it will change in near future...

@BalyshevArtem @chunseoklee @lemmaa About naming, Maybe we can be more specific, like runtime-lite/micro-runtime or something with runtime in the name?

[seanshpark]

I think there are some different understandings with lite

(1) /lite as group of lite modules

• /lite/runtime
• /lite/runtime-ex
• /lite/compiler
• /lite/...

(2) /lite as lite runtimes

• /lite/smaller-runtime
• /lite/faster-runtime
• /lite/...

(3) /lite for new home for luci-micro

• /lite

(1) and (2) are both OK with me. for (3) we have to add another root folder for another module. thus (3) is also OK to me too.

[BalyshevArtem]

@BalyshevArtem @chunseoklee @lemmaa About naming, Maybe we can be more specific, like runtime-lite/micro-runtime or something with runtime in the name?

runtime-lite/micro-runtime are both good for me, but I think better to use runtime-lite variant :)

[lemmaa]

Initially, I imagined (2) as a response of /runtime, and I think that (1) can also be accommodated without any problem by extending scope of (2).

In the case of (3), it is not clear what other name, like /lite , will be placed in / afterward. Would it be appropriate, or would it harmonize with the existing /compiler, /runtime and /lite? If there is an appropriate example of what will be come next /lite, it will help my understanding. :)

[seanshpark]

If there is an appropriate example of what will be come next /lite, it will help my understanding. :)

I think @BalyshevArtem 's runtime-lite would be the (3) case ?

/runtime-lite
  + /luci-interpreter
  + /standalone
  + CMakeLists.txt
  + README.md
  + requires.cmake

[BalyshevArtem]

If there is an appropriate example of what will be come next /lite, it will help my understanding. :)

I think @BalyshevArtem 's runtime-lite would be the (3) case ?

/runtime-lite
  + /luci-interpreter
  + /standalone
  + CMakeLists.txt
  + README.md
  + requires.cmake

Yes, this is how I imagined it

[lemmaa]

https://github.com/Samsung/ONE/issues/9699#issuecomment-1245216771

First of all, https://github.com/Samsung/ONE/issues/9699#issuecomment-1245205023 was a response to https://github.com/Samsung/ONE/issues/9699#issuecomment-1245130852

If there is an appropriate example of what will be come next /lite, it will help my understanding. :)

I think @BalyshevArtem 's runtime-lite would be the (3) case ?

The word next I mean is the sibling, not child, of /lite at the tree level.

/lite (or runtime-lite)
  + /luci-interpreter
  + /standalone
  + CMakeLists.txt
  + README.md
  + requires.cmake
/{next} <--- HERE
/{next next}

[seanshpark]

/{next} <--- HERE
/{next next}

Yes, I also thought the next would be another name in parallel with lite or runtime-lite. I can imagine;

• compiler-lite for compact compiler for on device
  • but as we put them multiple compilers in compiler this seems unrealistic.
• runtime-odl or runtime-learn for the runtime with on device learning capability,
  • we can put a switch inside existing runtime codes so this also can be just a imagination

I think there would be better names.

Another thought while writing this is that, when some requirement comes we can continue on this as a solution and think if its good or not.

[lemmaa]

@seanshpark , I think we are on the same page. Thanks for your clarification.

The part I was most concerned about in the folder structure is the independent CI configuration. This is to group modules that use the same CI trigger as the current /runtime or /compiler into one folder.

Like your opinion, I don't think there is a big difference between (1), (2), and (3) at the moment. If something needs to be added as a sibling of luci-micro in the future, we may consider whether to tie them together.

As for the name, either would be fine. If we go to (1) or (2), we have to think about a new group folder name, and if we go to (3), don't we already have a good name of luci-micro? I think it's up to @BalyshevArtem and @binarman. :)