search

contiki-os / contiki

The official git repository for Contiki, the open source OS for the Internet of Things
http://www.contiki-os.org/
Other
3.71k stars 2.58k forks source link

Thin contiki targets that do little to no bootstrapping #348

Open vsaw opened 11 years ago

vsaw commented 11 years ago

Seeing that simple changes in "top-level" applications like #346 have an effect on various targets I wonder if the targets are to fat in terms of the bootstrapping they do?

For a long time I have the feeling that targets should just initialize

and then launch into the main project process. Then inside the main project process a device can decide which other processes (e.g. resolv, tcpip or netstack) are required and start them.

This separation would also give the targets more flexibility in the configurations they run as the target would merely be a "board support code" so that any contiki code can be run on it.

Or is there any reason why these targets have become so fat other than not taking care of proper abstraction and refactoring?

oliverschmidt commented 11 years ago

As far as I understand your proposal is already partly implemented. Ie. see https://github.com/contiki-os/contiki/blob/master/examples/udp-ipv6/udp-client.c containing AUTOSTART_PROCESSES(&resolv_process,&udp_client_process);

However this seems to be one the (many) areas without a stringent style guideline. One question that comes into my mind is "what is the main project process"? For me it is in general quite unclear if the system is "owned" by a "main project process" - and how is that distinguished from the other processes? Or is the system rather "owned" by the Contiki OS just running a bunch of "equal" processes? IMHO this vagueness results from Contiki's history starting as a "general OS" moving towards a "project framework"...

vsaw commented 11 years ago

I know that the infrastructure is already there but still everything is put into the void contiki_main(void) function directly.

I imagine a simple three part separation.

  1. Platform: Initializes the Hardware
  2. Project: Bootstraps the configuration like MAC Addresses and runs the processes and apps (this is roughly the stuff in the examples folder)
  3. Apps: Can be included into different projects. Should be independent of platform.

With this clear guideline changes in apps do not need to alter the platforms. And projects can select the apps they want to run.

For me there is no question who owns the system. I just want to have a clear separation of setup und running the hardware. So I imagine the "project" to be like the linux init scripts which are tailored to each installation/use even if it is run on two copies the same hardware.