Re: [riot-devel] Fwd: 64bit and multi core support

[Alex Mavrin]

Hi Ludwig, Nhat,


Thanks a lot for your answers! It is much clearer now. We will estimate how
difficult it would be to adopt RIOT to our use case.

It is very attractive that RIOT is modular, supports C++ and aims to POSIX
compatibility.


I just wanted to thank you all again.


Regards,


Alex

On Thu, May 7, 2015 at 9:53 PM, Ludwig Ortmann 
wrote:

> Hi Alex,
>
> RIOT does not offer either.
>
> When I first wrote the native platform, I tried to support 64 bit but
> there were so many issues that I just chose to ignore it as there were no
> 64 bit platforms on the roadmap anyways.
> Since then two things changed:
> First, much work has gone into making integer types more explicit. Second,
> the native platform is relatively stable and offers valgrind support, so I
> think it could be used to make RIOT 64 bit safe relatively quickly.
>
> As for the scheduler - I'm not aware of any attempts at multicore support,
> but RIOT is very modular, so the scheduler could be changed/replaced with
> little trouble.
>
> Cheers,
> Ludwig
>
>
> Am 7. Mai 2015 20:33:41 MESZ, schrieb Alex Mavrin  >:
> >Dear RIOT team,
> >
> >
> >Thanks for RIOT I personally think it is GREAT!
> >
> >We are considering using RIOT on our ARM v8 64bit multicore (SMP)
> >hardware.
> >The platform requires 64bit memory addressing (DDR is at higher than
> >32bit
> >address range). We would appreciate if you could help us understand if
> >using RIOT is feasible by answering below questions:
> >
> >   1. Does RIOT support 64bit memory addressing? For example if I build
> >“hello-world” sample project on native platform then 32bit binary
> >generated. Is it possible to build it for 64bit? Have this been tested?
> >
> >
> >  2. Does RIOT support multi core? I.e. scheduling threads on different
> >cores, synchronizing threads running on different cores? Have this been
> >done before?
> >
> >
> >Best Regards,
> >
> >
> >Alex
>
>


-- 
Alex Mavrin
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

On 05/08/15 14:51, Oleg Hahm wrote:
> But why couldn't udp_send(vargs) not be wrapper/macro for X_send(PROTO_UDP,
> vargs)?
It definately could.

>> and this udp_send shouldn't have a pktsnip as parameter.
> 
> Well, you will have to specify a pointer to data. I guess the most stack
> agnostic way is using a void pointer than.
Well, whether it's char*, uint8_t* or void* doesn't really matter. I'd
go with char* for consistency with libc, but those are details...

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Oleg Hahm]

Hi!

> Exactly. In this case "udp_send" is part of the API I'd like to define.

But why couldn't udp_send(vargs) not be wrapper/macro for X_send(PROTO_UDP,
vargs)?

> Any application should just use udp_send, 

Yes!

> and this udp_send shouldn't have a pktsnip as parameter.

Well, you will have to specify a pointer to data. I guess the most stack
agnostic way is using a void pointer than.

Cheers,
Oleg
-- 
printk(KERN_WARNING "Hey who turned the DMA off?\n");
linux-2.6.6/drivers/net/wan/z85230.c


pgpECWuCKn5I9.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Oleg Hahm]

Hi Kaspar!

> int ng_netapi_send(kernel_pid_t pid, ng_pktsnip_t *pkt);
> 
> If we omit the messaging, and the pktbuf dependency, it is not "netapi"
> anymore.

For me netapi are basically four functions send(), set_receive_cb(), get() and
set(). This can be implemented as wrapper functions around IPC (as in the
nameless stack) or as direct function calls.
 
> Also, the default stack's whole design is based on threads passing
> messages containing pktsnips. Changing that would change the whole concept.

And nobody wants to do this.

> Applications now should be written in a network stack agnostic way.
> So if the stack implementor decides to go for the benefits of having
> clear module seperation and flexibility through using messages and
> threads, that still shouldn't force our application interfaces to that
> decision.

Agreed.

Cheers,
Oleg
-- 
The problem with token ring jokes is you need to wait your turn to laugh


pgpE2Jy3A4igw.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

On 05/08/15 14:38, Oleg Hahm wrote:
> I don't see the problem. In implementation A (the nameless stack) udp_send()
> calls netapi_send(UDP_THREAD_PID, pointers_to(ip_header+udp_header+payload))
> and in implementation B (nanonet) udp_send() calls netapi_send(active_pid,
> pointer_to(payload)).
Exactly. In this case "udp_send" is part of the API I'd like to define.

Any application should just use udp_send, and this udp_send shouldn't
have a pktsnip as parameter.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

On 05/08/15 14:34, Oleg Hahm wrote:
> Sure, from the caller perspective you don't care what's happening inside the
> stack, but what's so wrong in having the same API at all layers, i.e. inside
> and on top of the stack? (Assuming that it can be implemented without (or
> very, very, very little overhead.)

Well, netapi right now is

int ng_netapi_send(kernel_pid_t pid, ng_pktsnip_t *pkt);

If we omit the messaging, and the pktbuf dependency, it is not "netapi"
anymore.

Also, the default stack's whole design is based on threads passing
messages containing pktsnips. Changing that would change the whole concept.

Applications now should be written in a network stack agnostic way.
So if the stack implementor decides to go for the benefits of having
clear module seperation and flexibility through using messages and
threads, that still shouldn't force our application interfaces to that
decision.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Oleg Hahm]

Hi!

> That doesn't answer the question.
> 
> A "udp_send" could in one implementation fill a pktbuf and use netapi,
> in another implementation just call the underlying send functions and
> return only when the payload has been copied into the send buffer, not
> malloc'ing extra memory. That should be abstracted from the user, but in
> a way that doesn't force a stack to use netapi/pktbuf.

I don't see the problem. In implementation A (the nameless stack) udp_send()
calls netapi_send(UDP_THREAD_PID, pointers_to(ip_header+udp_header+payload))
and in implementation B (nanonet) udp_send() calls netapi_send(active_pid,
pointer_to(payload)).

Cheers,
Oleg
-- 
printk(CARDNAME": Bad Craziness - sent packet while busy.\n" );
linux-2.6.6/drivers/net/smc9194.c


pgp4mQolGQEfl.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Oleg Hahm]

Hi Kaspar!

> Actually, how a network stack internally communicates should be kept to
> that stack. I was talking exactly for the upper layers, e.g., applications.
> 
> How do I bind to a UDP or TCP port? How do I write to a TCP connection?

Well, no, than you're talking exactly about the second type of API. One (an
application or an application layer protocol) wants to send or receive
something over or from the network. At this point you have already a notion
about the network itself. From an application developer perspective you don't
care about this (sockets and so on), you basically only want to request or
share data.

From the caller perspective, what's so different between sending over UDP than
sending over raw IP? Even POSIX socket API allows that. As a sender I want to
specify the destination and the protocol (for both cases it should IMO be
possible to specify a best effort default).

My point was, that I don't see how it makes sense to design one API that can be
used for this purpose *and* protocols on top.
 
> My point is that something like
> 
> ---
> udp_socket_t s;
> udp_bind(&s, address, port);
> 
> udp_read(&s);
> ---
> 
> should be available. If the stack below is netapi based, then those
> calls should map to netapi calls. If not, whatever.

Sure, from the caller perspective you don't care what's happening inside the
stack, but what's so wrong in having the same API at all layers, i.e. inside
and on top of the stack? (Assuming that it can be implemented without (or
very, very, very little overhead.)

I'm not say that netapi is necessarily the API, we want to use on top, and I
agree with you, Kaspar, that we should look very carefully at it and eliminate
any hard dependency to threads or the packetbuffer and so on. But I agree with
Martine, that we shouldn't discard the idea of using netapi for this so
quickly.

Remember, netapi is very, very young. It's a good point in time to change it
*now*, in order to make it fit all our needs. If it turns out to be
impossible, well, then we have to look for something else.

> My first mail explains why I think that POSIX sockets are not suited for
> this.

And I think, there we all agree.

Cheers,
Oleg
-- 
/*
 * We used to try various strange things. Let's not.
 */
linux-2.2.16/fs/buffer.c


pgptDxfna8_GW.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

On 05/08/15 14:16, Oleg Hahm wrote:
>>> int ng_netapi_send(kernel_pid_t pid, ng_pktsnip_t *pkt);
>>
>> How do I use this without pktbuf or at least two threads?
> 
> Well, the memory for the packet (at least for the payload) has to be stored
> somewhere - at least until it is copied into the transceiver buffer.

That doesn't answer the question.

A "udp_send" could in one implementation fill a pktbuf and use netapi,
in another implementation just call the underlying send functions and
return only when the payload has been copied into the send buffer, not
malloc'ing extra memory. That should be abstracted from the user, but in
a way that doesn't force a stack to use netapi/pktbuf.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

On 05/08/15 12:36, Oleg Hahm wrote:
> IMO it is sensible to have a unified API with the feature set of netapi (or at
> least similar) for everything *below* application layer.

Actually, how a network stack internally communicates should be kept to
that stack. I was talking exactly for the upper layers, e.g., applications.

How do I bind to a UDP or TCP port? How do I write to a TCP connection?

My point is that something like

---
udp_socket_t s;
udp_bind(&s, address, port);

udp_read(&s);
---

should be available. If the stack below is netapi based, then those
calls should map to netapi calls. If not, whatever.

Now if I write a library or application, e.g., a coap server, I would
like to be able to write against this API, and a simple USEMODULE +=
STACK_A or STACK_B links in the right implementation.

My first mail explains why I think that POSIX sockets are not suited for
this.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Oleg Hahm]

Hi Kaspar!

> > int ng_netapi_send(kernel_pid_t pid, ng_pktsnip_t *pkt);
> 
> How do I use this without pktbuf or at least two threads?

Well, the memory for the packet (at least for the payload) has to be stored
somewhere - at least until it is copied into the transceiver buffer.

Cheers,
Oleg
-- 
If you don't see why, please stay the fuck away from my code.
Rusty, in linux-2.6.6/Documentation/DocBook/kernel-locking.tmpl


pgplR4xTJxW7K.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hey,

On 05/08/15 11:45, Martine Lenders wrote:
>> On 05/08/15 11:29, Martine Lenders wrote:
> it's wrapper functions [1], slightly renamed) could not be that API.

 Because it requires the use of messages, which implicitly requires using
 seperate threads. This is not feasable for low-memory systems.
>>>
>>> That's why I've put the emphasis on the wrapper functions of netapi.
>> Where can I find them? They're not in the header you cited?
>>
> 
> Of course they are:
> 
> int ng_netapi_send(kernel_pid_t pid, ng_pktsnip_t *pkt);

How do I use this without pktbuf or at least two threads?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Oleg Hahm]

Hi,

> protocols such as CoAP have a fundamentally different semantic than lower 
> layer
> protocols such as UDP or IP (GET/SET/PUT/DELETE vs. send/receive) and

sorry, of course I meant POST and not SET.

Cheers,
Oleg
-- 
printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good luck!\n",...);
linux-2.6.6/drivers/net/wan/lmc/lmc_main.c


pgpXoZQk4juO6.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] help

[Sonda Bousnina]

Hi,
Thank you all for your answers.
@Daniel: good luck for the OTA implementation in your project and let us
informed of your progress.
Have a nice day to all

On Fri, May 8, 2015 at 10:12 AM, Daniel Krebs  wrote:

>  I also intend to have OTA in my project. I'm going to help/implement it
> if that's neccessary, but it's still a milestone that's further down my
> roadmap.
>
>
> Am 08.05.2015 um 09:04 schrieb Baptiste Clenet:
>
> I would add that we all want this feature to be added to RIOT and we are
> pleased for any help to implement it :-)
>
> 2015-05-08 6:50 GMT+02:00 Ludwig Ortmann :
>
>> Hi,
>>
>> This is often called "firmware update" or "OTA" for "(firmware) over the
>> air".
>>
>> We don't have support for this yet, but it is planned, and there is some
>> information in the wiki (look for "OTA").
>>
>> Cheers,
>> Ludwig
>>
>> Am 8. Mai 2015 00:50:30 MESZ, schrieb Sonda Bousnina <
>> sondabousn...@gmail.com>:
>> >Hi,
>> >Thanks for your quick reply
>> >yes exactly, that what I mean
>> >
>> >On Fri, May 8, 2015 at 12:35 AM, Kaspar Schleiser 
>> >wrote:
>> >
>> >> Hi,
>> >>
>> >> On 05/08/15 00:23, Sonda Bousnina wrote:
>> >> > I'm wondering if it is possible to flash or update the code in the
>> >target
>> >> > board in real time while it is working without switching it off.
>> >> Not sure I understand the question.
>> >>
>> >> You mean, add/replace code while the device is running?
>> >>
>> >> Are you referring to updating the device in the field?
>> >>
>> >> Kaspar
>> >> ___
>> >> devel mailing list
>> >> devel@riot-os.org
>> >> https://lists.riot-os.org/mailman/listinfo/devel
>> >>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
>
>  --
>
> *Clenet Baptiste FR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> système temps réél embarqué*
>
>
> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014 *
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>


-- 
Best regards
Sonda BOUSNINA

Phd Student at  ANT Lab ( Advanced Network Technologies Laboratory)
http://antlab.elet.polimi.it/
Politecnico di Milano, Dip. di Elettronica, Informazione e Bioingegneria
Phd Student at  REGIM Lab (REserach Group on Intelligent Machines)
http://regim.org/
ENIS : National Engineering School of Sfax, University of Sfax, Sfax,
Tunisia.
IEEE Gold Member
IEEE Standards Association Member
IEEE Computer Society Member
IEEE Communications Society Member
IEEE Industry Applications Society Member
IEEE Women in Engineering WIE Member
IEEE Computer Society Merwin Student Ambassador in Region 8
sonda.bousn...@ieee.org; sondabousn...@gmail.com;
sonda.bousn...@computer.org
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Oleg Hahm]

Hi!

> If you agree that we need an API for embedded use, would you agree that
> this API should be the one that all RIOT internal libraries (e.g., for
> CoAP) should use?

I still wonder how sensible this is. To me, it seems that application layer
protocols such as CoAP have a fundamentally different semantic than lower layer
protocols such as UDP or IP (GET/SET/PUT/DELETE vs. send/receive) and
targeting a fundamentally different developer group (application developers or
even "users" that don't care about network internals vs. network protocol
developers that may live with a somewhat less abstracted API as long as it is
powerful and efficient enough).

IMO it is sensible to have a unified API with the feature set of netapi (or at
least similar) for everything *below* application layer. If I want to send a
payload from A to B, it should be matter of seconds to modify the send-call
from transmitting this payload over transport layer to transmitting over,
let's say, link layer.

Cheers,
Oleg
-- 
printk(KERN_WARNING "Hey who turned the DMA off?\n");
linux-2.6.6/drivers/net/wan/z85230.c


pgpa20Io2gccw.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi Kaspar,

2015-05-08 11:32 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/08/15 11:29, Martine Lenders wrote:
> >> On 05/08/15 11:14, Martine Lenders wrote:
> >>> Actually, yes. But I'm still trying to get my head around why netapi
> (or
> >>> it's wrapper functions [1], slightly renamed) could not be that API.
> >>
> >> Because it requires the use of messages, which implicitly requires using
> >> seperate threads. This is not feasable for low-memory systems.
> >
> > That's why I've put the emphasis on the wrapper functions of netapi.
> Where can I find them? They're not in the header you cited?
>

Of course they are:

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_SND messages
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] pkt pointer into the packet buffer holding the data to send
 *
 * @return 1 if packet was successfully delivered
 * @return -1 on error (invalid PID or no space in queue)
 */
int ng_netapi_send(kernel_pid_t pid, ng_pktsnip_t *pkt);

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_RCV messages
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] pkt pointer into the packet buffer holding the received data
 *
 * @return 1 if packet was successfully delivered
 * @return -1 on error (invalid PID or no space in queue)
 */
int ng_netapi_receive(kernel_pid_t pid, ng_pktsnip_t *pkt);

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_GET
messages and
 * parsing the returned @ref NG_NETAPI_MSG_TYPE_ACK message
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] opt option to get
 * @param[in] context (optional) context to the given option
 * @param[in] data pointer to buffer for reading the option's value
 * @param[in] max_len maximum number of bytes that fit into @p data
 *
 * @return value returned by the @ref NG_NETAPI_MSG_TYPE_ACK message
 */
int ng_netapi_get(kernel_pid_t pid, ng_netconf_opt_t opt, uint16_t context,
  void *data, size_t max_len);

/**
 * @brief Shortcut function for sending @ref NG_NETAPI_MSG_TYPE_SET
messages and
 * parsing the returned @ref NG_NETAPI_MSG_TYPE_ACK message
 *
 * @param[in] pid PID of the targeted network module
 * @param[in] opt option to set
 * @param[in] context (optional) context to the given option
 * @param[in] data data to set the given option to
 * @param[in] data_len size of @p data
 *
 * @return value returned by the @ref NG_NETAPI_MSG_TYPE_ACK message
 */
int ng_netapi_set(kernel_pid_t pid, ng_netconf_opt_t opt, uint16_t context,
  void *data, size_t data_len);

Cheers,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hey,

On 05/08/15 11:29, Martine Lenders wrote:
>> On 05/08/15 11:14, Martine Lenders wrote:
>>> Actually, yes. But I'm still trying to get my head around why netapi (or
>>> it's wrapper functions [1], slightly renamed) could not be that API.
>>
>> Because it requires the use of messages, which implicitly requires using
>> seperate threads. This is not feasable for low-memory systems.
> 
> That's why I've put the emphasis on the wrapper functions of netapi.
Where can I find them? They're not in the header you cited?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

On 05/08/15 11:14, Martine Lenders wrote:
> Actually, yes. But I'm still trying to get my head around why netapi (or
> it's wrapper functions [1], slightly renamed) could not be that API.

Because it requires the use of messages, which implicitly requires using
seperate threads. This is not feasable for low-memory systems.

If you check out my nanonet branch [1], there's a monolithic stack that
does Ethernet/IPV4/UDP/CoAP in about 5k RAM, with room for improvement.

If netapi would be used even just for CoAP, that stack would
unnecessarily be forced to put CoAP in its own thread, with all the
memory implications.

I'd like to avoid that.

Kaspar
[1] https://github.com/kaspar030/RIOT/tree/nanonet
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi,

2015-05-08 11:25 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 05/08/15 11:14, Martine Lenders wrote:
> > Actually, yes. But I'm still trying to get my head around why netapi (or
> > it's wrapper functions [1], slightly renamed) could not be that API.
>
> Because it requires the use of messages, which implicitly requires using
> seperate threads. This is not feasable for low-memory systems.
>

That's why I've put the emphasis on the wrapper functions of netapi.

Cheers,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi Kaspar,

2015-05-08 11:09 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 05/08/15 10:58, Martine Lenders wrote:
> > just to state the "opposite" opinion, too: while I see the need for an
> API
> > suitable for embedded use only and other stacks than the default one too,
> > I'm of the opinion, that the POSIX sockets (needed for library and
> > application ports) should also be as slim as possible. This means: A
> > wrapper (POSIX sockets) around a wrapper (the new new network API) around
> > some API (e. g. netapi) seems like overkill to me.
>
> If you agree that we need an API for embedded use, would you agree that
> this API should be the one that all RIOT internal libraries (e.g., for
> CoAP) should use?
>

Actually, yes. But I'm still trying to get my head around why netapi (or
it's wrapper functions [1], slightly renamed) could not be that API.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/ng_netapi.h
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

On 05/08/15 10:58, Martine Lenders wrote:
> just to state the "opposite" opinion, too: while I see the need for an API
> suitable for embedded use only and other stacks than the default one too,
> I'm of the opinion, that the POSIX sockets (needed for library and
> application ports) should also be as slim as possible. This means: A
> wrapper (POSIX sockets) around a wrapper (the new new network API) around
> some API (e. g. netapi) seems like overkill to me.

If you agree that we need an API for embedded use, would you agree that
this API should be the one that all RIOT internal libraries (e.g., for
CoAP) should use?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Network API task force

[Martine Lenders]

Hi Kaspar,
just to state the "opposite" opinion, too: while I see the need for an API
suitable for embedded use only and other stacks than the default one too,
I'm of the opinion, that the POSIX sockets (needed for library and
application ports) should also be as slim as possible. This means: A
wrapper (POSIX sockets) around a wrapper (the new new network API) around
some API (e. g. netapi) seems like overkill to me.

Cheers,
Martine

2015-05-08 10:18 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> at the last Network Stack Task Force meeting, we came to the conclusion
> that a task force for defining API's for network functionality like
> sockets or coap would be useful.
>
> So I'd like to start this and invite everyone to join!
>
> I'll start the discussion with my opinion on the need for a new socket API.
>
> It was discussed if we couldn't just adopt the BSD/POSIX socket API, as
> we would need that API anyways.
>
> In my opinion, it has some drawbacks for embedded usage. Best example:
> (From "man 7 socket"):
> --- snip ---
> SYNOPSIS
>#include 
>
>sockfd = socket(int socket_family, int socket_type, int protocol);
> --- snip ---
>
> This is the function that creates a socket and returns a handle. In
> malloc-capable systems, this is perfectly fine. In RIOT, the question
> arises, what does the returned fd mean?
>
> The socket will definately need some state. This needs to be somewhere
> in memory. Using that API, we'd need to either preallocate a certain
> amount of socket state structures, or use malloc. Both ways suck.
>
> So a new socket library might more look like:
>
> --- snip ---
> socket = socket(socket_t *sock, blah) ...
> --- snip ---
> That way, the caller has to provide all memory needed for managing the
> socket.
>
> We do it like that all over RIOT, so I'd like to see this adopted for
> sockets.
>
> I also believe that it is very easy to implement BSD sockets once these
> RIOT sockets are in place, adding the memory burden. It is not possible
> to do it the other way around...
>
> Thoughts?
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Network API task force

[Kaspar Schleiser]

Hi,

at the last Network Stack Task Force meeting, we came to the conclusion
that a task force for defining API's for network functionality like
sockets or coap would be useful.

So I'd like to start this and invite everyone to join!

I'll start the discussion with my opinion on the need for a new socket API.

It was discussed if we couldn't just adopt the BSD/POSIX socket API, as
we would need that API anyways.

In my opinion, it has some drawbacks for embedded usage. Best example:
(From "man 7 socket"):
--- snip ---
SYNOPSIS
   #include 

   sockfd = socket(int socket_family, int socket_type, int protocol);
--- snip ---

This is the function that creates a socket and returns a handle. In
malloc-capable systems, this is perfectly fine. In RIOT, the question
arises, what does the returned fd mean?

The socket will definately need some state. This needs to be somewhere
in memory. Using that API, we'd need to either preallocate a certain
amount of socket state structures, or use malloc. Both ways suck.

So a new socket library might more look like:

--- snip ---
socket = socket(socket_t *sock, blah) ...
--- snip ---
That way, the caller has to provide all memory needed for managing the
socket.

We do it like that all over RIOT, so I'd like to see this adopted for
sockets.

I also believe that it is very easy to implement BSD sockets once these
RIOT sockets are in place, adding the memory burden. It is not possible
to do it the other way around...

Thoughts?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] help

[Daniel Krebs]

I also intend to have OTA in my project. I'm going to help/implement it 
if that's neccessary, but it's still a milestone that's further down my 
roadmap.


Am 08.05.2015 um 09:04 schrieb Baptiste Clenet:
I would add that we all want this feature to be added to RIOT and we 
are pleased for any help to implement it :-)


2015-05-08 6:50 GMT+02:00 Ludwig Ortmann >:


Hi,

This is often called "firmware update" or "OTA" for "(firmware)
over the air".

We don't have support for this yet, but it is planned, and there
is some information in the wiki (look for "OTA").

Cheers,
Ludwig

Am 8. Mai 2015 00:50:30 MESZ, schrieb Sonda Bousnina
mailto:sondabousn...@gmail.com>>:
>Hi,
>Thanks for your quick reply
>yes exactly, that what I mean
>
>On Fri, May 8, 2015 at 12:35 AM, Kaspar Schleiser
mailto:kas...@schleiser.de>>
>wrote:
>
>> Hi,
>>
>> On 05/08/15 00:23, Sonda Bousnina wrote:
>> > I'm wondering if it is possible to flash or update the code
in the
>target
>> > board in real time while it is working without switching it off.
>> Not sure I understand the question.
>>
>> You mean, add/replace code while the device is running?
>>
>> Are you referring to updating the device in the field?
>>
>> Kaspar
>> ___
>> devel mailing list
>> devel@riot-os.org 
>> https://lists.riot-os.org/mailman/listinfo/devel
>>

___
devel mailing list
devel@riot-os.org 
https://lists.riot-os.org/mailman/listinfo/devel




--
/Clenet Baptiste
FR: +33 6 29 73 05 39/
/Élève-Ingénieur ESEO Angers, dernière année, spécialisation: 
Architecte système temps réél embarqué//

/
/Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014

/


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] help

[Baptiste Clenet]

I would add that we all want this feature to be added to RIOT and we are
pleased for any help to implement it :-)

2015-05-08 6:50 GMT+02:00 Ludwig Ortmann :

> Hi,
>
> This is often called "firmware update" or "OTA" for "(firmware) over the
> air".
>
> We don't have support for this yet, but it is planned, and there is some
> information in the wiki (look for "OTA").
>
> Cheers,
> Ludwig
>
> Am 8. Mai 2015 00:50:30 MESZ, schrieb Sonda Bousnina <
> sondabousn...@gmail.com>:
> >Hi,
> >Thanks for your quick reply
> >yes exactly, that what I mean
> >
> >On Fri, May 8, 2015 at 12:35 AM, Kaspar Schleiser 
> >wrote:
> >
> >> Hi,
> >>
> >> On 05/08/15 00:23, Sonda Bousnina wrote:
> >> > I'm wondering if it is possible to flash or update the code in the
> >target
> >> > board in real time while it is working without switching it off.
> >> Not sure I understand the question.
> >>
> >> You mean, add/replace code while the device is running?
> >>
> >> Are you referring to updating the device in the field?
> >>
> >> Kaspar
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> >>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*


*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel