Proposal for sys folder

Development archive
1

Dear RIOT developers,

While working on the documentation refactor, I’ve had the impression the sys folder has turned into a “everything that doesn’t match core, cpu, etc” folder.

I’ve seen some implicit categories:

  • Actual sys (auto_init, event queues, C++ wrapper, power management, etc)

  • Network (high layers, stacks, etc)

  • Libs/Tools (hashes, filters, parsers, etc)

Although the Network modules have their own section 1 in the documentation, sometimes it’s not easy to follow what belongs to a system component or what is a lib with an API that can be used from an application. Also IMO, specially for new developers, is not that easy to follow this folder structure.

I want to know your comments on the following proposals:

  1. Move the net folder to the RIOTBASE folder (sys/net -> sys): This is consistent with our documentation, generates less folder depth, makes refactoring easier. The Linux kernel does exactly the same [2].

  2. Add a lib folder in the RIOTBASE:

  3. Move cryptos, serializers, parsers, math, etc. to this lib folder.

  4. Keep RIOT sys related stuff in the sys folder. This could be, for instance, stuff in direct communication with the RIOT kernel and layers interacting with periphs (auto_init, xtimer, power management, maybe file systems).

Looking forward to your comments.

Cheers,

José

2

Hi José,

thanks for tackling this!

  1. Move the net folder to the RIOTBASE folder (sys/net → sys):

I suppose you mean ‘/sys/net’ ->‘/net’ This idea has been floating around for a while, and I think there was consensus at some point on doing that. Just never got to be done :wink: +1 from my side.

  1. Add a lib folder in the RIOTBASE:

  2. Move cryptos, serializers, parsers, math, etc. to this lib folder.

  3. Keep RIOT sys related stuff in the sys folder. This could be, for instance, stuff in direct communication with the RIOT kernel and layers interacting with periphs (auto_init, xtimer, power management, maybe file systems).

Sounds sensible to me, but others may have more informed opinions.

Cheers

Emmanuel

3

Hi Emmanuel,

I suppose you mean ‘/sys/net’ ->‘/net’

Oops, yes. I meant /net folder.

Cheers, José

4

Hi,

1. Move the `net` folder to the RIOTBASE folder (`sys/net` -> `sys`): This is consistent with our documentation, generates less folder depth, makes refactoring easier. The Linux kernel does exactly the same [2]. 2. Add a `lib` folder in the RIOTBASE: 1. Move cryptos, serializers, parsers, math, etc. to this `lib` folder. 2. Keep RIOT sys related stuff in the `sys` folder. This could be, for instance, stuff in direct communication with the RIOT kernel and layers interacting with periphs (auto_init, xtimer, power management, maybe file systems).

+1!

Would it make sense to then move core, drivers, sys, net, lib, boards, cpu into src/? Is there something sensible like "hw" where we could put cpu, boards, drivers? Should periph and netdev move to sys?

For network I find it a little difficult. IMO some parts are more sys/net, others are more lib/net. Eg., everything that sits on top of sock (and is stack independent) could be considered "library code".

Kaspar

5

Hi Kaspar, all

Would it make sense to then move core, drivers, sys, net, lib, boards, cpu into src/? Is there something sensible like "hw" where we could put cpu, boards, drivers? Should periph and netdev move to sys?

A `src` folder makes sense to me. Could you explain more about the `hw` folder?

Also, `boards` and `cpu`(and maybe `drivers` as well) are IMO in a special category: they could be defined in a folder outside of the RIOT repo, or even in another public/private repository. Would be nice if they can be seen in RIOT as "reference target implementation" rather than a kernel module. `drivers` are a special case, but there's still the case where closed source drivers can be defined without touching the RIOT repo.

Does it make sense?

I like the idea of moving `periph` and `netdev` to sys.

For network I find it a little difficult. IMO some parts are more sys/net, others are more lib/net. Eg., everything that sits on top of sock (and is stack independent) could be considered "library code".

I agree with this.

I also see a third category here that should be handled as well, the network stack itself. E.g with GNRC, lwip and gcoap: - GNRC and lwip need to implement `netdev` and `sock` in order to abstract the network device and the application layer => `netdev` and `sock` are closer to `sys/net` - gcoap can be used with several network stacks => it's closer to `lib/net` - GNRC and lwip are in the same level as network stacks => Where should these be located?

Anyway, we could already start migrating some obvious `lib` modules (hashes, crypto, parsers, etc).

Cheers, José