Re: [riot-devel] Mandatory netif header?
Hi,
> In my opinion a protocol running logically directly above the link-layer,
> such as IP (adaptation layers like 6LoWPAN may exist in between) will
> typically require information about the interface that received the
packet.
> (The same is true for other layers, e.g. UDP cannot work without
information
> from the IP header.)
While your statement is true for UDP the argument does not hold for IP in
my opinion. UDP (or TCP) need the IP information, because IP otherwise
doesn't know how to send the packet, since UDP does not handle this kind of
information. IP on the other hand has ARP/NDP to resolve an IP address into
link-layer information. Furthermore, as far as we discussed so far we
talked only about reception of a packet and there this information is only
important for routing protocols and IP-internal stuff (and for the most
part only the non-address related information from these header, like the
interface identifier and the link-layer metrics). In these cases the
information is provided for natural interfaces. Pseudo-interfaces as you
define them usually are not handled by these kind of operation in a
sensible way so packets from those can just ignore packets without a netif
header.
> Not in all cases a physical interface may be involved, but for those cases
> there should typically be a pseudo-interface. The only case, where we do
not
> have a pseudo-interface right now (as far as I know) is the loopback case.
> In my opinion, it is - for efficiency reasons - completely okay not to
> provide a loopback device in GNRC, but I still don't see a reason why a
> netif header indicating a pseudo interface should do any harm here.
> Implementation detail:
> So far, KERNEL_PID_UNDEF is used as identifier in my proposal, but we
could
> also define the PID of the IPv6 thread as loopback device identifier.
Well unless you want to send all IPv6 packets to the loopback to the IPv6
thread this would require an additional check anyways.
> Finally, I think asserting a present netif header makes the code easier,
> because one does not have to cover exception cases and provide different
> branches for netif-header-is-present and netif-header-is-NOT-present.
I have the complete opposite impression: Currently the check for a netif
header is AFAIK only present at the point of your patch. So we have a
little bit more complex code at this point (where the complexity is only as
far as a `assert(netif)` vs `if(netif) { iface = netif->iface } else {iface
= KERNEL_PID_UNDEF}`), while anything else that is a pseudo-interface now
needs to prepend a netif header to the packet.
Cheers,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Question about RIOT/tests/thread_msg
Hi Jianwen,
thread_msg does a context switch between p3 and p1 because p1 does not have
a message queue.
The second message from p3 causes p3 to go into a blocked state and give up
control otherwise the previous message will be lost.
if in p1 a msg_queue is defined:
void *thread1(void *arg)
{
(void) arg;
msg_t msg_queue[8];
msg_init_queue(msg_queue, 8);
puts("THREAD 1 start\n");
...
then thread_msg example will run as documented until the message queue is
full.
I hope this little explanation may help ...
ciao
Attilio
On Thu, Mar 31, 2016 at 10:35 AM, OuyangJianwen
wrote:
> Hello,
>
> I am a new beginner to learn RIOT. I got some question when I run the
> "thread_msg" on board "SAMR21-xpro".
>
> For the thread1, thread2 and thread3, they have the same priority. so when
> the thread3 is running, how can scheduler switch to the thread1.
>
> I saw these in the API:
> "In case of equal priorities, the threads are scheduled in a
> semi-cooperative fashion. That means that unless an interrupt happens,
> threads with the same priority will only switch due to voluntary or
> implicit context switches."
> and
> "Some functions that unblock another thread, e.g. msg_send()
>
> or mutex_unlock()
> ,
> can cause a thread switch, if the target had a higher priority."
>
> but here, all the three threads have the same priority, so according the
> rule, even there is msg_send()
> ,
> the thread3 should not be blocked and run forever, but it doesn't.
>
> Thanks for your time!
>
> Regards,
> Jianwen OUYANG
>
>
>
> ___
> 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] Bi-weekly meeting
Dear rustling IOTlers, since Kaspar cannot attend today's meeting, but would be strongly interested in the topic about the purpose of the repository, we decided to postpone this discussion (it's not urgent anyway and with the upcoming release we have other things to do, I guess). Since this was the only proposed topic on the agenda, I would propose to cancel today's meeting. Any objections? Cheers, Oleg On Tue, Apr 05, 2016 at 02:50:24PM +0200, Francisco Javier Acosta Padilla wrote: > Hi RIOT folks! > > As usual, we have our bi-weekly RIOT developers meeting, until today, these > are the topics to discuss present in the agenda: > > - overall purpose of the RIOT repository > > Feel free to add other topics of your interest. > > Cheers, > > -- > Francisco Javier Acosta Padilla > Research Engineer at INRIA Saclay > INFINE Team > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ linux-2.4.3/net/core/netfilter.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Mandatory netif header?
Dear resolving IOTlers, in several lengthy discussions on Github we (mostly Martine and me) discussed if the netif header in GNRC should be mandatory. As a context: the netif header in GNRC is a pseudo-header that contains (optional) link-layer information such as the source and destination address, the information about the used interface, and some additional, again optional, information about link-layer metrics (RSSI and LQI). Until recently, it was optional to include this header while passing the packet up the stack. However, recently, I introduced a patch to change this, by asserting the presence of the netif header while receiving a packet in the IPv6 implementation. The current discussion is about reverting this change. My rationale to _keep_ this change is the following: * In my opinion a protocol running logically directly above the link-layer, such as IP (adaptation layers like 6LoWPAN may exist in between) will typically require information about the interface that received the packet. (The same is true for other layers, e.g. UDP cannot work without information from the IP header.) * Not in all cases a physical interface may be involved, but for those cases there should typically be a pseudo-interface. The only case, where we do not have a pseudo-interface right now (as far as I know) is the loopback case. In my opinion, it is - for efficiency reasons - completely okay not to provide a loopback device in GNRC, but I still don't see a reason why a netif header indicating a pseudo interface should do any harm here. Implementation detail: So far, KERNEL_PID_UNDEF is used as identifier in my proposal, but we could also define the PID of the IPv6 thread as loopback device identifier. * Finally, I think asserting a present netif header makes the code easier, because one does not have to cover exception cases and provide different branches for netif-header-is-present and netif-header-is-NOT-present. Cheers, Oleg -- The bad thing about HTML DOM jokes is that everyone has their own interpretations, so you have to tell them 9000 different ways. signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
