Re: [riot-devel] What is UHCP?

[Oleg Hahm]

Hi Martine,

On Mon, Nov 02, 2020 at 12:26:43PM +0100, Martine Sophie Lenders wrote:
> UHCP (micro host configuration protocol) is a RIOT-proprietary protocol
> that was developed back in 2016 [1] to have a simple drop-in replacement
> for DHCPv6 prefix delegation (which was not implemented yet back then).

thanks for the explanation. Now that I read it I actually remember it. ;-)

Would you mind to just copy-paste this explanation into the doxygen
documentation?

Cheers
Oleg
-- 
panic("Lucy in the sky");
linux-2.2.16/arch/sparc64/kernel/starfire.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] What is UHCP?

[Oleg Hahm]

Dear reconnecting IOTlers,

I just came across the following page in the RIOT documentation:
https://riot-os.org/api/group__net__uhcp.html

Could anybody explain what UHCP is and how it works? The documentation page is
a bit minimalistic and I couldn't find an RFC or similar.

Cheers
Oleg
-- 
panic("IRQ, you lose...");
linux-2.2.16/arch/mips/sgi/kernel/indy_int.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Help with SODAQ SARA SFF needed

[Oleg Hahm]

Hey folks,

I'm currently trying to get RIOT to fly on the SODAQ SARA SFF board.
Unfortunately I'm struggling a little bit with the startup sequence of the
U-Blox module. According to the documentation here:
http://doc.riot-os.org/sodaq-sara-sff_2include_2board_8h.html and the Arduino
samples provided by SODAQ I assumed that I would need to call SARA_ENABLE_ON
and SARA_TX_ENABLE_ON, followed by toggling SARA_R4XX_PWR_ON_PIN, but I still
fail to read the firmware via an AT command. Anyone with experience with the
SODAQ boards and the SARA U-Blox module?

Cheers
Oleg
-- 
panic ("No CPUs found.  System halted.\n");
linux-2.4.3/arch/parisc/kernel/setup.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] ztimer - a new high-level timer for RIOT

[Oleg Hahm]

Hey Kaspar,

On Mon, Dec 09, 2019 at 11:28:19PM +0100, Kaspar Schleiser wrote:
> > Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking
> > here. CPU time or memory? Probably both, right? Regarding the CPU 
> > efficiency,
> > I would assume that this also dictates the maximum precision, right?
> 
> I don't think so. The hardware dictates the maximum precision.

my thinking here was: when I set the timer to fire in 1 time units, but the
function to set a timer takes 2 time units, then the maximum precision is 2
time units.
 
> > Regarding memory we have probably different requirements: ROM for the
> > whole thing, RAM per instance and for the module itself.
> 
> Here, the requirement should be "needs to fulfill all other
> requirements", and from that point on, less is better.

What do you mean by "all other requirements"?

> But all the requirements don't help over the fact that xtimer currently
> just doesn't work for many identified use cases.
> require substantial code changes, probably including API changes.
> Knowning the complexity of xtimer, I decided to give a rewrite from
> scratch a try, and IMO, the result is quite nice.

I got this. But since we are going for a clean re-design we should take the
opportunity and get the requirements straight first.

But to get this straight: I don't see the need that you must collect all the
requirements yourself.

Cheers
Oleg
-- 
panic("Tell me what a watchpoint trap is, and I'll then 
deal with such a beast...");
linux-2.2.16/arch/arch/sparc/kernel/traps.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] ztimer - a new high-level timer for RIOT

[Oleg Hahm]

Hey!

On Mon, Dec 09, 2019 at 10:07:16PM +0100, Kaspar Schleiser wrote:
> > Anyway, I think we need to define what "very efficient timers for use in
> > time-critical drivers" means in order to being able to check whether the
> > proposal fulfills the requirement or not.
> 
> We can try. What would that look like?
> Something like "must not incur more than x us overhead on hardware of
> class y"?

Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking
here. CPU time or memory? Probably both, right? Regarding the CPU efficiency,
I would assume that this also dictates the maximum precision, right? Regarding
memory we have probably different requirements: ROM for the whole thing, RAM
per instance and for the module itself.

> > Besides I'm missing a requirement regarding the maximum granularity and the
> > maximum duration of a timer.
> 
> You mean minimum granularity?

In my understanding of the term maximum granularity translates to the finest
granularity.

Cheers
Oleg
-- 
T he bes thin gabou tTCPfl owcontr oljokesi sthatthey knowwhento backo ff
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] ztimer - a new high-level timer for RIOT

[Oleg Hahm]

Folks!

Can we get back to the actual problem at hand, please?

Let me recap:
Kaspar came up with a proposal for a new timer API, since xtimer has flaws (as
identified by multiple members of the RIOT community during the last ~4 years)
and is apparently not fixable (at least no one came up with a concrete
proposal to fix it to the best of my knowledge). Having a concrete
implementation proposal is great.

Thanks for the effort of designing and implementing the current state of
ztimer and thanks for the documentation of this effort!

I think the problem statement and the requirements could indeed be more
precise - while I must admit that a lack of precise requirements is a failure
of the RIOT community.

Anyway, I think we need to define what "very efficient timers for use in
time-critical drivers" means in order to being able to check whether the
proposal fulfills the requirement or not.

Besides I'm missing a requirement regarding the maximum granularity and the
maximum duration of a timer.

Cheers
Oleg
-- 
The good thing about object oriented jokes is they bring their own laughter
method.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Some thoughts on the typical RIOT workflow

[Oleg Hahm]

Dear reviewing IOTlers,

the RIOT maintainer meeting that happened yesterday triggered some thoughts
about our common workflow [1] when it comes to pull request introducing new
features, new hardware support, or new concepts.

The first observation is that proposing something new goes often along with
quite a bunch of implementation already done. On the one hand, this sometimes
steer discussions into the wrong direction where some people already start to
dig into implementation details while the discussion about the general
approach haven't yet concluded. On the other hand, the contributor is much
more reluctant to change his or her approach (or even give up on it) because
so much time has been spent for implementing it.

The second observation is that the typical scenario is that a single person
proposes a pull request and then tries to convince the rest of the community
that the idea and realization are good and worthwhile to be integrated into
RIOT master. Depending on the openness of this person regarding feedback and
his or her responsiveness the lifetime of the pull request and the effort
spent on it (from both sides) can easily explode.

As an idea how to tackle both problems, I think it could be useful to change
this "one against all" approach (over-exaggerating here, of course). If
someone wants to propose something new, he or she could ask for a somewhat
experienced RIOT developer to pair up with (we could think of it as a sparring
partner and sponsor if you like). So, one could first discuss the idea and the
realization approach with this partner, before actually starting the
implementation. Then, both (or potentially more people) would present the PR
to the rest of the community and try to defend and improved it together.

Cheers
Oleg

[1] Excuse me for still talking about "we" and "us" here although I haven't
contributed anything for a long time. And also excuse me if I'm not taking
recent developments in this respect into account.
-- 
panic("smp_callin() a\n");
linux-2.6.6/arch/parisc/kernel/smp.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Incorporating OMG Data-Distribution Service for Real-Time Systems (DDS)

[Oleg Hahm]

Hey Brenton,

On Tue, Jul 02, 2019 at 02:14:30PM +0200, Brenton Chetty wrote:
> Is anyone currently working on incorporating DDS into RIOT?

maybe you could try to contact the authors of
https://ieeexplore.ieee.org/abstract/document/8442103 [1]

Cheers
Oleg

[1] Beckman, Kai, and Jonas Reininger. "Adaptation of the DDS Security
Standard for Resource-Constrained Sensor Networks." 2018 IEEE 13th
International Symposium on Industrial Embedded Systems (SIES). IEEE, 2018.
-- 
DPRINTK("Last time you were disconnected, how about now?\n");
linux-2.6.6/drivers/net/tokenring/ibmtr.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Test - please ignore

[Oleg Hahm]

Please ignore
-- 
printk ("%s: This looks like a LART board to me.\n",module_name);
linux-2.6.6/drivers/mtd/devices/lart.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Driver design rules in RIOT

[Oleg Hahm]

Hi Juan!

Just a small comment:

On Wed, Sep 26, 2018 at 12:16:08PM +0200, Juan Ignacio Carrano wrote:
> Maybe off topic, but I think we need a IO layer (think SAUL, but more
> complete) so that the user does not have to directly interact with drivers.
> I would answer many of your questions, as in that case there would be a well
> defined interface that device drivers would have to expose. It is an OS,
> after all.

It is an *embedded* OS, after all. Speaking from experience: Trying to design
a too generalized driver API is at best difficult, mostly dangerous.
("API Generalization leads to bloat. Bloats to leads to memory consumption.
Memory consumptions leads to suffering.")

Maybe you can elaborate a little bit more on the "more complete" part?

Cheers,
Oleg
-- 
panic("Fod fight!");
linux-2.2.16/drivers/scsi/aha1542.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Notification: Monthly RIOT developer meeting @ Mon Sep 24, 2018 4pm - 5pm (CEST) (RIOT Events)

[Oleg Hahm]

Hey Paco!

On Mon, Sep 24, 2018 at 03:46:32PM +0200, Francisco Javier Acosta Padilla wrote:
> Well, there’s the developers meeting today, and I’d like to
> take the opportunity to talk about some recent things on RIOT,
> e.g. build system and dependencies, which might touch other
> topics as well.
> 
> Please fill the agenda at  [1] and let’s meet using jitsi at
> [2].

Would be good to have the link to the agenda a little bit more in advance,
i.e., at least one day before the meeting, for the next meetings.

Cheers,
Oleg
-- 
panic("esp_handle: current_SC == penguin within interrupt!");
linux-2.2.16/drivers/scsi/esp.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Dec 26, 2017 5pm - 10pm (RIOT Events)

[Oleg Hahm]

Dear reindeering IOTlers,

is this gonna happen tonight?

Cheers,
Oleg

On Mon, Dec 25, 2017 at 03:59:56PM +, Google Calendar wrote:
> This is a notification for:
> 
> Title: Hack'n'ACK
> When: Tue Dec 26, 2017 5pm – 10pm Berlin
> Where: FU Berlin; HAW Hamburg
> Calendar: RIOT Events
> Who:
> * Martine Lenders - creator
> 
> Event details: 
> https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNzEyMjZUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn
> 
> Invitation from Google Calendar: https://www.google.com/calendar/
> 
> You are receiving this email at the account peterschme...@gmail.com because
> you are subscribed for notifications on calendar RIOT Events.
> 
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings for
> this calendar.
> 
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn more at
> https://support.google.com/calendar/answer/37135#forwarding

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


-- 
DPRINTK("Last time you were disconnected, how about now?\n");
linux-2.6.6/drivers/net/tokenring/ibmtr.c


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

Re: [riot-devel] Data Caching in GNRC, Vol 57, Issue 16

[Oleg Hahm]

Hi Benjamin,

On Fri, Nov 17, 2017 at 04:56:33PM +, Häring Benjamin (haej) wrote:
> > Regarding caching: no there is no possibility in GNRC to cache data for
> > sleeping nodes at the moment.
> Is such a solution planned for the GNRC? The stack would thus only be
> applicable to nodes with sufficient energy supply or not?

Caching is not part of the IP network stack. IMO it wouldn't make no sense at
all to implement it as part of GNRC. If you want caching, I would suggest to
either take a look at 
1) CoAP resource directory [1],
2) OpenThread [2] or
3) ICN [3].

Cheers,
Oleg

[1] https://tools.ietf.org/html/draft-ietf-core-resource-directory-12
[2] https://openthread.io/platforms/riot
[3] http://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-60-slides.pdf
-- 
/* Host controller interrupts must not be running while calling this
 * function or the penguins will get angry. */
linux-2.2.16/drivers/usb/ohci.c


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

[riot-devel] Minutes from the road map session at the RIOT summit

[Oleg Hahm]

Dear road-mapping IOTlers,

it took me way too long, but finally I managed to transcribe the handwritten
notes from our road map session at the summit some weeks ago into the wiki:
https://github.com/RIOT-OS/RIOT/wiki/RIOT-Summit-roadmap-session-2017

I tried my best to summarize our discussions, but you will probably spot some
items where you could improve and/or extend my notes. Please feel free to
directly edit the wiki page.

Since there are no blue or pink sheet at RIOT meetings, I couldn't recall all
the names of the attendees. So please add your name to the attendees list, in
case you attended but are not listed there.

Two decisions about concrete actions items that were made, but haven't been
implemented so far (as far as I know):
 * Take the discussion about how to document the stability level for supported
   hardware platforms to this mailing list. I remember that Kaspar agreed to
   do so. Am I right?
 * Organize some bi-weekly developer meeting/call. Paco wanted to take the
   lead on this if I remember correctly.

Cheers,
Oleg
-- 
Dprintk("oh dear, we are idle\n");
linux-2.6.6/drivers/net/ns83820.c


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

Re: [riot-devel] rtc alarm running with threads

[Oleg Hahm]

Dear Paula,

can you share the code of your application somewhere? That might help to find
the issues. I would suppose that the interrupt handler is faulty or consumes
too much memory or something like this.

I think start debugging with a basic application that just prints some text
whenever a message from the RTC interrupt is received is a smart idea. Now, we
need to figure out what exactly triggers the kernel panic. Are you compiling
your application with the DEVELHELP macro enabled? And which port are you
using? Maybe you can use `make debug` to get more information.

Cheers,
Oleg
-- 
/* Fuck, we are miserable poor guys... */
linux-2.6.6/net/xfrm/xfrm_algo.c


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

Re: [riot-devel] Jimini Board support announcement

[Oleg Hahm]

Dear Josua,

On Thu, Oct 19, 2017 at 02:38:35PM +, Arndt, Josua wrote:
> I'm happy to announce the support of a new board develop at the IAS of the
> RWTH Aachen. The initial PR is ongoing, it will be followed by driver and
> module PRs soon. Have a closer look at the wiki page to get an overview and
> insight of our development state.

cool, this sounds great. I particular appreciate the efforts you've spent in
creating the wiki page for the board and updating relevant information!

Thanks a lot and keep up the good work,
Oleg
-- 
T he bes thin gabou tTCPfl owcontr oljokesi sthatthey knowwhento backo ff


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

Re: [riot-devel] RPL DAO target concat from fib

[Oleg Hahm]

Hi Rahul!

Just a small remark regarding one of your comments:

On Thu, Oct 19, 2017 at 11:16:17AM +0530, Rahul Jadhav wrote:
> 2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for
> e.g. ETX).
> Pls correct if i m wrong.

One problem here is that not all radio devices report back the number of L2
retries if this is implemented by the device itself. In some cases it is
possible to deactivate this feature and take care of L2 ACK handling and
retries as part of the device driver, but this is currently not implemented
for all drivers.

Cheers,
Oleg
-- 
HTTP Error 413: That’s what she said!


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

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

[Oleg Hahm]

Hey Thomas!

I agree with Kaspar: thanks for bringing this up and yes, we should aim for
compliance.

On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote:
> A while ago I worked on adding support for MAC commands and procedures the
> standard describes like channel scanning and automatic association of a
> device with a coordinator.
> Personally I think those are nifty features to provide, the reality check
> the last two days showed though that it'd need some non-trivial refactoring
> of the existing 15.4 code to not end up in #ifdef hell.

Can you elaborate a little bit on this part? I would assume that being
compatible with other 802.15.4 implementations requires run-time flexibility,
i.e., react properly to optional features implemented by other 802.15.4
devices. Or were you proposing to have a minimal non-standard-compliant
version _and_ standard-compliant version intermingled, sharing commmon code
through preprocessor directives?

Cheers,
Oleg
-- 
panic("If this is a 64-bit machine, please try a 64-bit kernel.\n");
linux-2.6.6/arch/parisc/kernel/inventory.c


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

Re: [riot-devel] IPv4 support

[Oleg Hahm]

Dear Ameya!

On Fri, Aug 18, 2017 at 06:38:31PM +0530, Ameya Joshi wrote:
> Does the latest version of RIOT support IPv4?

RIOT supports the lwip network stack which supports IPv4. However, AFAIK there
is no IPv4 support for application interface "sock". Martine, correct me if
I'm wrong.

Cheers,
Oleg
-- 
die_if_kernel("Penguin instruction from Penguin mode??!?!", regs);
linux-2.2.16/arch/sparc/kernel/traps.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Mailserver issues

[Oleg Hahm]

Hi Adam!

On Fri, Aug 11, 2017 at 04:04:05AM -0700, Adam Hunt wrote:
> Just out of curiosity, was this due to a lack of machine resources?

Actually not. In fact, the maximum number of MTA and content filter processes
were configured too low.

> How is RIOT's infrastructure (e.g. web and mail hosting) handled; is
> the hosting donated by one or more of the supporters listed at the
> bottom of the project's homepage? Would additional hosting resources
> be helpful?

Currently, some of the services (e.g., web and mail) are hosted privately by
community members, other services are sponsored by supporting institutions
such as FU Berlin, HAW Hamburg, and Inria. In general, additional resources
are always helpful, particular for the CI system, I guess. Do you have
something particular in mind?

Cheers,
Oleg
-- 
/* Ugly, ugly fucker. */
linux-2.6.6/include/linux/netfilter_ipv4/ipt_limit.h
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Re-visiting the LED macros

[Oleg Hahm]

Hi Hauke!

On Tue, Jul 11, 2017 at 06:04:29PM +0200, Hauke Petersen wrote:
> For the purpose of profiling using GPIO pins, I think it makes more sense to
> think about something like a CPU specific `pin_debug` header for a small
> number (say 2?) pins that can be directly (say without overhead) controlled.
> The actual pins used should still be configured by the board, but we can put
> default pins in place and we don't need all this redundant pin wobble
> clutter in a board's configuration.

I don't fully get this point. How would this header differ from the current
LED control?

Besides, I would still vote for keeping the LED macros, because they are so
simple that you can always rely on them - even in case you have fucked
something completely up. Splitting them into a different header and maybe even
make them optional, however, is fine with me.

Cheers,
Oleg
-- 
printk(KERN_ERR "scsi%d: !!BINGO!! Falcon has no lock in NCR5380_abort\n", ...)
linux-2.6.6/drivers/scsi/atari_NCR5380.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] At86rf2xx ACK frame

[Oleg Hahm]

Hi Alex!

On Fri, Jun 16, 2017 at 10:43:05PM +0200, Alexander Aring wrote:
> On Fri, Jun 16, 2017 at 09:45:25PM +0200, Oleg Hahm wrote:
> > Using at86rf2xx's extended operating mode allows you to figure out if an ACK
> > was received or not, but not all models allows you to read if and how many
> > retransmissions were necessary.
> 
> Question here is:
> 
> Is "how many retransmissions were necessary" is a required information
> for IEEE 802.15.4 MLME-ops? If so, then the transceiver hardware has a
> lack of support to implement IEEE 802.15.4, if not then this is some
> "extra" feature. Not sure if this information is required. Required
> information for some MLME-ops is if finally there was an ACK or NOT, no
> matter how many retransmissions was involved.

Hm, you can still use the base operation mode and implement "everything"
(i.e., ACK handling, retransmissions etc.) yourself. Hence, the transceiver
hardware is capable - it's just a matter of implementation comfort.

> Such "extra" feature could only be useful to check how reliable a peer
> is, maybe?.

True.

Cheers,
Oleg
-- 
printk(KERN_WARNING "%s: Thanks, I feel much better now!\n", dev->name);
linux-2.6.6/drivers/net/de620.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] At86rf2xx ACK frame

[Oleg Hahm]

Hi Alex!

On Fri, Jun 16, 2017 at 09:21:18PM +0200, Alexander Aring wrote:
> On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote:
> > On 2017-06-16 11:27, Baptiste Clenet wrote:
> > > Yes Thomas I haven't tried yet but I don't think transceiver stores it.
> > > Joakim, OpenThread requires it as explained here:
> > > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978
> > 
> > Sorry, I don't get the explanation. Why does OpenThread needs the pointer to
> > the ACK frame?
> > 
> 
> Some IEEE 802.15.4 MLME-ops requires if the ack was received or not.
> This need be handled by upper layers e.g. a SoftMAC layer of IEEE
> 802.15.4. So actually if ARET is supported by hardware and it's an
> SoftMAC transceiver it should have the possibility to read out some
> status register of handled ARET algorithm on hardware side if ACK was
> there or not (because MLME-ops requires this information). If hardware
> can't report and is a SoftMAC transceiver with ARET support and can't
> handle MLME-ops on hardware side: you have a problem.

Using at86rf2xx's extended operating mode allows you to figure out if an ACK
was received or not, but not all models allows you to read if and how many
retransmissions were necessary.

Cheers,
Oleg
-- 
printk (KERN_ERR "%s: Oops - your private data area is hosed!\n", ...)
linux-2.6.6/drivers/net/ewrk3.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Package

[Oleg Hahm]

Hi!

On Wed, May 17, 2017 at 10:21:45AM +0200, Baptiste Clenet wrote:
> I see! Very interesting feature and I really think it should be
> enabled by default! What's your opinion?

Not sure what you mean. The feature is enabled by default, the only thing you
need to do is to add git-cache to your $PATH.

Cheers,
Oleg
-- 
/* Fuck me gently with a chainsaw... */
linux-2.0.38/arch/sparc/kernel/ptrace.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Package

[Oleg Hahm]

Hi Baptiste!

On Wed, May 17, 2017 at 10:08:50AM +0200, Baptiste Clenet wrote:
> So you mean that git-cache is already used and allow to download an
> archive of a .git repo?

Yes, but you have to "install" git-cache first (see dist/tools/git/README.md).

> Could you give me an example of a package that is download as an
> archive and store so you don't need to git clone again?

Every git-based package uses git-cache, e.g. nanocoap or ccn-lite.

Cheers,
Oleg
-- 
Yo mamma is so fat that she sat on a binary tree and made it a linked list in
constant time.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Package

[Oleg Hahm]

Hi Baptiste,

On Wed, May 17, 2017 at 08:24:50AM +0200, Baptiste Clenet wrote:
> Concerning external package, I suggest that RIOT download and store
> the archive in pkg folder then extract here in the right location to
> be compiled. This is helpful when you work on a package so you don't
> need to download it again every time after a `make clean` or when you
> compile another example, you need to download it again.
> What do you think?

for Git-based packages you can use git-cache for exactly this purpose [1].

Cheers,
Oleg

[1] https://github.com/kaspar030/git-cache 
-- 
RAID joke are always redundant
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Release 2017.04

[Oleg Hahm]

Yay, congrats everybody and thanks for the great release management, Kaspar!

On Wed, May 10, 2017 at 01:04:43PM +0200, Kaspar Schleiser wrote:
> Dear RIOTers,
> 
> we are happy to announce the 11th official release of RIOT:
> 
> --- * RIOT 2017.04 * ---
> 
> This release provides a lot of new features, fixes and enhancements.
> Among these has been a huge cleanup regarding cppcheck and
> documentation, and we're pleased to announce that all remaining doxygen
> and cppcheck warnings have been fixed.
> We're also proud to present a Virtual File System layer and integration
> of the SPIFFS file system.
> A lot of work has gone into support for STMicroelectronics's Nucleo
> family, with RIOT now supporting 28 (up from 13) Nucleo boards. And as
> always, there was a lot of under-the-hood cleanup, bug fixing and
> documentation work.
> 
> About 200 pull requests with about 562 commits have been merged since
> the last release and about 23 issues have been solved. 32 people
> contributed with code in 91 days. 2697 files have been touched with
> 716950 insertions and 492623 deletions.
> 
> You can download the RIOT release from Github by cloning the repository
> [1] or by downloading the tarball [2], and look up the release notes for
> further details [3].
> 
> Thanks everyone for your contributions, discussions, testing efforts,
> and keep RIOTing!
> 
> Happy hacking,
> Kaspar
> 
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.04
> [2] https://github.com/RIOT-OS/RIOT/archive/2017.04.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/2017.04-branch/release-notes.txt
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
HTTP Error 413: That’s what she said!
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Regarding RIOT joining EdgeX Foundry

[Oleg Hahm]

Hey Thomas!

On Tue, May 02, 2017 at 01:24:12PM -0700, Thomas Eichinger wrote:
> Thanks for your feedback. I think there is no such thing as an official
> trial trial period so I understand correctly that this trial period would be
> a RIOT internal thing?

Yupp, that's what I meant. Sorry for my sloppy wording.

Cheers,
Oleg
-- 
The good thing about object oriented jokes is they bring their own laughter
method.


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

[riot-devel] [CFP] Elsevier FGCS Journal [IF=2.43] -- SI on "Internet of Things (IoT): Operating System, Applications and Protocols Design, and Validation Techniques"

[Oleg Hahm]

Dear researching IOTlers,

please find below a call for papers for Special Issue in Elsevier Future
Generation Computer Systems Journal that might be interesting for some of you.

Apologies if you receive multiple copies of this announcement.

---
CALL FOR PAPERS

Special Issue in Elsevier Future Generation Computer Systems Journal.
"Internet of Things (IoT): Operating System, Applications and Protocols
Design, and Validation Techniques"

Submission Deadline: June 30, 2017

THE THEME
--
Internet of Things (IoT) connects durable goods, cars and trucks, industrial
and utility components, and sensors to Internet with data analytics
capabilities. IoT is flourishing due to technology advancements. The key
features of IoT Operating Systems (OSs) are modularity, energy-efficient
scheduler, hardware support, architecture, network stacks, reliability,
interoperability, unified APIs, generic interfaces, and real-time
capabilities. The applications for IoT service scenarios are diverse and
challenging. These range from smart energy, transportation, etc. to big data
analysis. The integration of all these applications is essential to eventually
make everything smart. The memory and energy efficient IoT protocols are
desirable. The validation of IoT protocols and applications is a key to
success. Therefore, an IoT OS requires to support not only a huge variety of
heterogeneous hardware, but also simulators and emulators as well as testbed
facilities Further, it should provide th e capability to perform small scale
to large scale testing with heterogeneous physical devices and communication
technologies. The availability of variety of IoT OSs, low-cost IoT devices,
heterogeneous telecommunications technologies, big data technologies and
standardization is a key of success for IoT deployment. To fully exploit these
technological advancements, there exists many issues related to applications,
protocols, testing, interoperability; time bounded big data processing and
analysis, heterogeneous communication technologies and platform support.  This
Special Issue focuses on the most recent advancement in interdisciplinary
research areas encompassing IoT OSs, applications and protocols design,
development, and validation domain. This Special Issue will bring together
researchers from diverse fields such as communication engineering, computer
engineering, computer science, electrical and electronics engineering,
bio-informatics and mathematics. Through this Special Issue, we invite
researchers from industry, academia and government organizations to discuss
innovative ideas and contributions, demonstrate results and share
standardization efforts on the IoT OSs and related areas.  Topics of interest
include, but not limited to the following:

· IoT Operating Systems (OSs)
oEnergy and memory efficient approaches
oSensors, IoT platform support and limitations in IoT OSs
oInteroperability of IoT OSs protocols and devices
oSimulation, emulation and testbed support, limitations and Solutions
oResource management for IoT OSs
oMemory management for resource constrained IoT devices
oSecurity issues and solutions for privacy in IoT OSs
oCo-existence of technologies, limitation and solutions
oStandard API specifications for IoT OSs

· Applications for IoT Service Scenario
oSmart energy
oSmart transportation
oSmart waste management
oSmart buildings
oSmart physical safety and security
oSmart health care
oSmart education
oSmart Personal Network (SPN)
oEdge Computing
oCooperative and smart sensing approaches
oSensor data collection and management
oEfficient big data techniques, processing, and analysis

· Protocol overview, issues and solutions
oIoT physical layer protocols 
oIoT MAC layer protocols
oIoT network layer protocols
oIoT transport layer protocols
oIoT applications
oRadio Duty Cycling (RDC)
oCross layer protocol design

· Modeling of IoT heterogeneous wireless technologies, protocols and 
applications
· Simulator/Emulator issues and  improvements
· Testbed deployment and testing


Submission Guidelines:
-

All submissions have to be prepared according to the Guide for Authors as
published in the Journal website at http://ees.elsevier.com/fgcs/. Authors
should select “IoT:OS,App,Proto,Valid”, from the “Choose Article Type”
pull-down menu during the submission process at EVISE. All contributions must
not have been previously published or be under consideration for publication
elsewhere. A submission based on one or more papers that appeared elsewhere
has to comprise major value-added extensions over what appeared previously (at
least 30% new material). Authors are requested to attach to the submitted
paper their relevant, previously published 

Re: [riot-devel] flash command without compiling

[Oleg Hahm]

Hi!

On Tue, Apr 18, 2017 at 10:12:13AM +0200, Kaspar Schleiser wrote:
> On 04/17/2017 04:47 PM, Jose Alamos wrote:
> > I noticed the 'make flash' recompiles everything before flashing. What's
> > the reason behind this?
> 
> Does it actually recompile?
> 
> The flash target in Makefile.include depends on the "all" target, ensuring
> that the build is up-to-date. I guess at some point we thought that is a
> good idea.

I remember that (years ago) I thought that this would be a bad idea, but got
overruled. IIRC the reasoning was that otherwise `make flash` may fail.

Cheers,
Oleg
-- 
printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
linux-2.2.16/drivers/char/msp3400.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] HacknAck 27.3.2017

[Oleg Hahm]

Hey James!

On Mon, Mar 27, 2017 at 03:40:47PM +0200, James Munns wrote:
> I was planning to attend the Hack n' Ack tomorrow in Berlin, and some of
> the maintainers I met at Embedded World suggested that I ping the mailing
> list to make sure it was still happening :).
> 
> I don't have anything specific to talk about, but I thought it would be
> good to meet some (more) of the maintainers. Let me know if the meeting is
> still on for this week.

I can confirm that the Hack'n'Ack is gonna happen tomorrow at least in Berlin
and probably Hamburg. You (and everybody else) are welcome to join us after
work at FU Berlin in Dahlem (Room 137, Institute for Computer Science,
Takustr. 9).

See you tomorrow,
Oleg
-- 
panic("esp: what could it be... I wonder...");
linux-2.2.16/drivers/scsi/esp.c


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

Re: [riot-devel] RIOT's CI system

[Oleg Hahm]

Hi Martin!

On Tue, Mar 21, 2017 at 01:21:22PM +0100, Landsmann, Martin wrote:
> While going through the spreadsheet I stumbled upon row 28, i.e. 'Cope with
> dynamic set of workers'.
> 
> I would appreciate to get more information why the scoring seems to state,
> what I interpret of it,
> 
> that Jenkins is totally unable to handle the cases, or does it in an abysmal
> way.

I think it's probably Cenk who can answer this question in the most detailed
way, but in general we judged only the current state of the CI
(configuration) to avoid fortune telling. In the current state of Jenkins it
cannot deal with failing workers, but would require some non-trivial exception
handling in a groovy file.

To all the other members of the task force: correct me if I remembered this
wrong.

Cheers,
Oleg
-- 
/* Fuck.  The f-word is here so you can grep for it :-)  */
linux-2.4.3/include/asm-mips/mmu_context.h


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

Re: [riot-devel] RIOT's CI system

[Oleg Hahm]

Hi Thomas!

On Mon, Mar 20, 2017 at 11:17:07AM -0700, Thomas Eichinger wrote:
> Reading the document provided it seems to me that Jenkins actually
> got a better score than Murdock 2. (Please tell me if I am mistaken
> and misinterpret the table.)

No, you are correct. Jenkins got a slightly higher score than Murdock, but the
scoring system is not really balanced and the difference is only ~5% and hence
negligible.

> Because of this I'd very much appreciate a little bit more of information
> on why this group came to the conclusion Murdock 2 is still better
> fitting RIOT than Jenkins.
> 
> I do not intend to bash the task force results just try to better
> understand the reasoning.

No worries, actually, I appreciate your inquiry. Indeed the conclusion was
that both CI systems are well suited for our needs. Jenkins may be a bit
stronger in some aspects while Murdock 2 scores in other aspects. Finally, we
wanted to come up with a concrete proposal and decided to recommend Murdock 2
for a rather indirect argument: whatever CI is chosen, we can never be certain
that we're gonna to be happy with that decision forever (as the past has
shown). However, if we now decide for Jenkins it is very likely that the
development of Murdock 2 will stop and we can never go back - while the other
way should be always possible.

I hope that answers your question(s). Otherwise, please let me know and I will
happily try to explain it better.

Cheers,
Oleg
-- 
printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
linux-2.2.16/drivers/char/msp3400.c


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

[riot-devel] RIOT's CI system

[Oleg Hahm]

Dear robust IOTlers,

as you probably know we're currently running three CI systems in parallel:
Murdock, Jenkins and Murdock 2, where the first one is the authoritative CI
system and the other two are under test. Since these two last systems support
distributed deployment - a must-have feature for us - we need to replace
Murdock with one of it.

In order to decide whether we should use Jenkins or Murdock 2, a task force
was formed to deploy and thoroughly evaluate both systems. This task force
finally defined 34 criteria categorized into Web UI, GitHub Interface,
Performance, Operation, Maintenance, Security, and Extensibility for the
evaluation. The outcome was that both tools seem to fulfill the criteria
satisfactorily well. You can find the result of the evaluation at [1].

Hence, it was a close call, but eventually, we (the members of the task force)
agreed that we want to switch to Murdock 2 as the default CI system. Murdock 2
is currently developed by Kaspar particular for the needs of RIOT and
therefore simplifies configuration. It is also seems to scale better and
outperform Jenkins. 

Please let us know if you disagree with our assessment and object switching to
Murdock 2 as the authoritative CI.

Cheers,
Oleg

[1] 
https://docs.google.com/spreadsheets/d/1_KxHZmuDb-j4IfNZt-XSTW711NESWTxfMX46YppoTic/edit?usp=sharing
-- 
printk("ip6t_hook: happy cracking.\n");
linux-2.6.6/net/ipv6/netfilter/ip6table_filter.c


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

Re: [riot-devel] netdev2 is now netdev

[Oleg Hahm]

Hi Martine!

Thanks for the info. Just a short clarification question:

On Wed, Mar 15, 2017 at 11:46:47AM +0100, Martine Lenders wrote:
> The only pitfall that might be a problem I was able to identify when
> porting is that the adaption layer to GNRC `gnrc_netdev2` is now called
> `gnrc_netdev`. So if you still include `sys/include/net/gnrc/netdev.h`
> somewhere make sure to remove it or replace it with an include of
> `drivers/include/net/netdev.h`.

That means that I need to write #include "net/netdev.h", right?

Cheers,
Oleg
-- 
/* The HME is the biggest piece of shit I have ever seen. */
linux-2.6.6/drivers/scsi/esp.h


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

Re: [riot-devel] To global seed or not to global seed

[Oleg Hahm]

Hi Ludwig!

On Wed, Mar 08, 2017 at 10:28:13AM +0100, Ludwig Knüpfer wrote:
> Am 8. März 2017 10:21:15 MEZ schrieb Oleg Hahm <oliver.h...@inria.fr>:
> >Is testing and simulation the only use case you can imagine? I'm somewhat
> >reluctant to add code just for non-production purposes.
> 
> Since we outspokenly target researchers with RIOT this is a production 
> feature.
> 
> However we might want to move this feature into a dedicated implementation
> of the same interface.

Thanks, that was more or less what I meant.

Cheers,
Oleg
-- 
The problem with TCPIP jokes is that when I tell them, all I want is an ACK but
usually get FINs and RSTs


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

Re: [riot-devel] To global seed or not to global seed

[Oleg Hahm]

Dear Cenk,

thanks for bringing up this discussion.

On Wed, Mar 08, 2017 at 12:18:28AM +0100, Cenk Gündoğan wrote:
 
> 1) we can define it as BCP to *not* use `random_init()` if `auto_init`
>is used
>=> it's hard to guarantee a one-time call to `random_init()` as human
>do surely err (especially if several nested modules are involved).

Basically, we have similar problems for other modules that should (or even
must) not be initialized twice. So far, my/our take on this was to document
this rather than programmatically prevent this. The memory overhead is small,
but existent, the runtime overhead is probably negligible for a function that
should not be called more than once.

> In contrast to the current procedure of having a global state, we rather
> should opt to allow local states for each thread (not excluding a global
> state).

Is testing and simulation the only use case you can imagine? I'm somewhat
reluctant to add code just for non-production purposes.

Cheers,
Oleg
-- 
/* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */
 *
 * Wirzenius wrote this portably, Torvalds fucked it up :-)
 */
linux-2.2.16/lib/vsprintf.c


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

Re: [riot-devel] Release 2017.01

[Oleg Hahm]

Great, finally we have an Enterprise[1] release! ;-)

Thanks a lot for the wonderful efforts, everybody, and, of course, particular
Peter for the often cumbersome work as the release manager!

Cheers,
Oleg

[1] https://en.wikipedia.org/wiki/USS_Enterprise_(NCC-1701)

On Wed, Feb 01, 2017 at 06:29:26PM +0100, Peter Kietzmann wrote:
> Dear RIOTers,
> 
> we are happy to announce the tenth official release of RIOT:
> 
> 
> --- * RIOT 2017.01 * ---
> 
> This release provides a lot of new features, fixes and enhancements.
> Among others these features contain an initial - still experimental -
> TCP implementation based on the GNRC network stack, support for reading
> from and writing to SD cards, a new power management architecture as
> well additional third party packages such as TweetNaCl, a cryptographic
> library, and Heatshrink a data compression library optimized for
> embedded real-time systems. We added support for new  platforms
> including the Calliope mini, Maple mini, and a couple of STMs Nucleo
> boards. Device support was extended by several new drivers, e.g., for
> NXP PN532 NFC, Microchip MRF24J40 802.15.4 radio (experimental), or
> Bosch BME280 pressure/humidity/temperature sensor.
> We completely refactored the SPI interface, allowing for internally
> handled hardware or software chip select lines and shared bus usage for
> multiple devices with different SPI configurations.
> 
> About 278 pull requests with about 606 commits have been merged since
> the last release and about 84 issues have been solved. 44 people
> contributed with code in 87 days. 2230 files have been touched with
> 220275 insertions and 159840 deletions.
> 
> You can download the RIOT release from Github by cloning the repository
> [1] or by downloading the tarball [2], and look up the release notes for
> further details [3].
> 
> Thanks everyone for your contributions, discussions, testing efforts,
> and keep RIOTing!
> 
> Best regards
> Peter
> 
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.01
> [2] https://github.com/RIOT-OS/RIOT/archive/2017.01.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/2017.01-branch/release-notes.txt
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
panic("Lucy in the sky");
linux-2.2.16/arch/sparc64/kernel/starfire.c


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

Re: [riot-devel] Ethos in Mac OS

[Oleg Hahm]

Hi Adeel!

I'm trying to understand your question:

On Mon, Jan 30, 2017 at 12:58:59PM +, Adeel Mohammad Malik wrote:
> I have managed to run CCN-lite in RIOT on a border router with Ethernet as
> the underlying layer on the north bound interface and CCN on 802.15.4 on the
> southbound interface. 

Do I understand this correctly: you've already achieved this, right?

  ccn-liteccn-lite
Internet <--- Ethernet ---> RIOT <--- 802.15.4 ---> Lowpan

Now you want to change this to:

  ccn-liteccn-lite
  Ethernet
Internet <--- Serial   ---> RIOT <--- 802.15.4 ---> Lowpan

Is this correct?

Cheers,
Oleg

-- 
fs_dprintk (FS_DEBUG_IRQ, "Iiiin-coming (0)\n");
linux-2.6.6/drivers/atm/firestream.c


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

Re: [riot-devel] Proposal: Use Gitter to allow users and developers easier and simpler chat functionality

[Oleg Hahm]

Hi Anthony!

On Wed, Jan 18, 2017 at 02:49:37PM -0500, Anthony Merlino wrote:
> Here is an example https://gitter.im/Microsoft/vscode 

Thanks. Seems rather slow/resource-hungry. Is there a non-Web (or even better:
a non-GUI) version?
 
Cheers,
Oleg
-- 
My computer is so slow that sometimes it gets a timeout from http://localhost.


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

Re: [riot-devel] Proposal: Use Gitter to allow users and developers easier and simpler chat functionality

[Oleg Hahm]

Hi Anthony,

Welcome to RIOT and thanks for your suggestions.

On Wed, Jan 18, 2017 at 02:03:05PM -0500, Anthony Merlino wrote:
> I am a relatively new user to Riot OS. I understand that this type of
> proposal from a new user may be frowned upon or unwarranted. So I understand
> if this idea gets shot down and closed. However, I would like to see if
> there is any interest in using Gitter rather than freednode and the mailing
> lists (or maybe the mailing lists stay in parallel) for developers and users
> to chat.

I would certainly not drop any of our current communication channels because
they have proven to work well and are based on established open standard
communication protocols.

> I have worked with other open source projects (ardupilot for one) that use
> Gitter for real-time interactions between developers and with users. The
> interface is clean and easy to use, integrates with GitHub nicely, and has
> infinite message persistence.

I've never heard of Gitter before. What kind of protocol does it use? Which
client exist? Can you provide at least a pointer to it?

> Does anyone else think this would be a big improvement in helping the
> community grow?

As I have never heard of this tool before, I have my doubts, but I know that
I'm not always up-to-date when it comes to these type of tools. For me E-Mail
is still the best communication channel in 90% of all cases.

Cheers,
Oleg

P.S. If you want to follow the discussion, you probably want to subscribe to
the mailing list.
-- 
The best thing about CSS jokes is that they are misunderstood and taken
incorrectly by Internet Explorer.


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

Re: [riot-devel] Stacksize optimization

[Oleg Hahm]

Hi!

On Mon, Jan 09, 2017 at 02:01:04PM +0100, Baptiste Clenet wrote:
> In order to optimize the statcksize of a thread, I would like to know
> when the thread uses the maximum of its stack (maximum can be 3/4 of
> the stack for instance)
> How can I find this "time"?

Sounds like a case for -finstrument-functions (man gcc).

Cheers,
Oleg
-- 
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
linux-2.2.16/arch/sparc/kernel/traps.c


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

Re: [riot-devel] Strange errors

[Oleg Hahm]

Hi Ilias!

On Mon, Jan 09, 2017 at 11:54:46AM +0100, Ilias Seitanidis wrote:
> Today I came up with some strange errors while creating a new project.
> The first one is "'CREATE_STACKTEST' undeclared (first use in this function)
>  THREAD_PRIORITY_MAIN - 1, CREATE_STACKTEST,"
> 
> my code is "kernel_pid_t pid = thread_create(second_thread_stack,
> sizeof(second_thread_stack),
> THREAD_PRIORITY_MAIN - 1, CREATE_STACKTEST,
> second_thread, NULL, "pong");"
> -I used the same code ~7 months ago and it was working.

CREATE_STACKTEST got renamed some time ago:
$ git grep CREATE_STACKTEST
core/include/thread.h: *  @ref THREAD_CREATE_STACKTEST  | measures the stack's 
memory usage

I.e., it's called THREAD_CREATE_STACKTEST now.

(See also http://doc.riot-os.org/group__core__thread.html)

> The second one is "implicit declaration of function 'xtimer_usleep_until'
> [-Werror=implicit-function-declaration]
>   xtimer_usleep_until(_wakeup, INTERVAL);"
> 
> - I use the same code in another project and works

xtimer_sleep_until() got refactored to xtimer_periodic_wakeup() in
4449ba493350a3683d48a91934aa767409c42ec7

$ git log | grep -B2 xtimer_usleep_until
Merge pull request #5612 from gebart/pr/xtimer-periodic-wakeup
xtimer: Refactor xtimer_usleep_until and rename to xtimer_periodic_wakeup

(See also http://doc.riot-os.org/group__sys__xtimer.html)

Cheers,
Oleg
-- 
panic("Unable to find empty mailbox for aha1542.\n");
linux-2.2.16/drivers/scsi/aha1542.c


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

Re: [riot-devel] Biweekly virtual meeting @ Wed Jan 11, 2017 2pm - 3pm - Agenda Update

[Oleg Hahm]

Hi Vincent!

On Wed, Jan 04, 2017 at 01:39:16PM +0100, Vincent Dupont wrote:
> I would like to join as this topic is central in the CAN stack developments,
> but I won't be available next Wednesday.
> Could this be rescheduled ?

Sure, do you want to propose some dates in a doodle?

Cheers,
Oleg
-- 
panic("bad_user_access_length executed (not cool, dude)");
linux-2.0.38/kernel/panic.c


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

[riot-devel] Biweekly virtual meeting @ Wed Jan 11, 2017 2pm - 3pm - Agenda Update

[Oleg Hahm]

Dear roaring IOTlers,

I would like to revive the virtual RIOT developer meeting next week and put a
topic on the agenda that was raised several times in the past by different
people: a (generic) memory allocator. One of the use cases for such a feature
was described here:
https://github.com/RIOT-OS/RIOT/issues/6097

Please feel free to put other topics on the agenda
(http://www.yourpart.eu/p/ByuA3s6InO)

Cheers,
Oleg
-- 
The best thing about CSS jokes is that they are misunderstood and taken
incorrectly by Internet Explorer.


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

Re: [riot-devel] sha256

[Oleg Hahm]

Hey Paco!

On Fri, Dec 16, 2016 at 06:47:19PM +0100, Francisco Javier Acosta Padilla wrote:
> I’m trying the sha256 module on RIOT master and I just realised it returns
> always a different value… for now, I’m doing this:
> 
> 
> sha256_init();
> sha256_update(, (uint8_t*)firmware_bin, firmware_size);
> sha256_final(, metadata.hash);
> 
> To initialise and store the hash, according to the unittest which does very
> similar.
> 
> Am I doing something wrong?

Strange. At a first glance your code seems to be valid for me. Could you share
a pointer to your project? Is maybe first somehow corrupted or is metadata a
part of firmware_bin?

Cheers,
Oleg

-- 
DPRINTK("strange things happen ...\n");
linux-2.6.6/drivers/atm/eni.c


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

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Oleg Hahm]

Hi Kaspar!

On Tue, Nov 29, 2016 at 11:59:14AM +0100, Kaspar Schleiser wrote:
> On 11/29/2016 11:14 AM, Oleg Hahm wrote:
> > Okay, re-reading the documentation again, I agree that the behavior deviates
> > from what is written. I also see, that the behavior is indeed different on
> > different architectures which is clearly a bug.
> 
> Turns out this is done similarily on all platforms...

Except MSP430, ARM7, native, and x86, you mean? ;-)

Cheers,
Oleg
-- 
printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",...);
linux-2.6.6/drivers/net/sundance.c


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

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Oleg Hahm]

Hi Kaspar!

On Tue, Nov 29, 2016 at 10:41:11AM +0100, Kaspar Schleiser wrote:
> On 11/29/2016 10:27 AM, Oleg Hahm wrote:
> > I would call it rather a bug in the documentation. The behavior of the
> > scheduler for threads of the same priority is simply underspecified.
> 
> We had that discussion offline. The "bug" is both in Cortex-M's ISR
> handling and in the docs.

Okay, re-reading the documentation again, I agree that the behavior deviates
from what is written. I also see, that the behavior is indeed different on
different architectures which is clearly a bug.

> > "Assigning the same priority to two or more threads is usually not a good
> > idea. A thread in RIOT may run until it yields (thread_yield) or another
> > thread with higher priority is runnable (STATUS_ON_RUNQUEUE) again. Multiple
> > threads with the same priority will therefore be scheduled cooperatively: 
> > when
> > one of them is running, all others with the same priority depend on it to
> > yield (or be interrupted by a thread with higher priority).
> 
> This last half sentence (in braces) is wrong. A higher thread might
> interrupt one with "siblings" of the same priority, but after the
> high-prio thread is done, the scheduler would switch back to the initial
> thread.

That's probably my fault. I always thought that `sched_run()` would advance
the pointer which is apparently not true.

Cheers,
Oleg
-- 
The great thing about SQL transaction jokes is that once you BEGIN, you can
ROLLBACK if nobody gets them.


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

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Oleg Hahm]

Hi Kaspar!

On Tue, Nov 29, 2016 at 08:46:58AM +0100, Kaspar Schleiser wrote:
> On 11/26/2016 12:55 AM, Charles Cross wrote:
> > Perhaps this is designed for the case where actions are taken inside the
> > ISR which signal other threads (like sending IPC messages), but I'm
> > still not clear on why it would need to reschedule the previously
> > executing thread relative to other running or pending threads of equal
> > priority.
> 
> Your analysis is correct, and you might have found a bug in the
> scheduling logic.

I would call it rather a bug in the documentation. The behavior of the
scheduler for threads of the same priority is simply underspecified. The only
thing the API says here is:

"Assigning the same priority to two or more threads is usually not a good
idea. A thread in RIOT may run until it yields (thread_yield) or another
thread with higher priority is runnable (STATUS_ON_RUNQUEUE) again. Multiple
threads with the same priority will therefore be scheduled cooperatively: when
one of them is running, all others with the same priority depend on it to
yield (or be interrupted by a thread with higher priority). This may make it
difficult to determine when which of them gets scheduled and how much CPU time
they will get. In most applications, the number of threads in application is
significantly smaller than the number of available priorities, so assigning
distinct priorities per thread should not be a problem. Only assign the same
priority to multiple threads if you know what you are doing!"
[Source: https://riot-os.org/api/group__core__thread.html]

Hence, if we change the scheduler and update the documentation accordingly, we
should also make sure that the pointer in the list of threads with equal
priority is not advanced if a thread gets interrupted by a thread with a
higher priority, either. I.e., the pointer should only be advanced if a thread
explicitly calls `thread_yield()`.

Cheers,
Oleg
-- 
What's a pirate's favorite method of remote access? - ADP


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

Re: [riot-devel] RIOT Release 2016.10

[Oleg Hahm]

Hi!

That's awesome and I'm really happy to see another RIOT release out there to
conquer the IoT! ;-)

Many thanks to Martine for thoroughly managing this release and putting so
much work into it. And congrats for the fastest release - only 100 days! [1]

And of course, also many thanks to the whole RIOT community for having 
contributed
another great set of new features, bug fixes, and new hardware support!

Cheers,
Oleg

[1] https://github.com/RIOT-OS/RIOT/wiki/release-statistics

On Fri, Nov 11, 2016 at 04:07:46PM +0100, Martine Lenders wrote:
> Dear RIOTers,
> 
> we are happy to announce the ninth official release of the RIOT:
> 
> --- * RIOT 2016.10 * 
> ---
> 
> This release provides a lot of new features as well as it fixes several major
> bugs. Among these new features are the new simplified network socket API
> called sock, the GNRC specific CoAP implementation gcoap and several new
> packages: TinyDTLS, the Aversive++ microcontroller library for robotics, the
> u8g2 graphic library, and nanocoap.
> Using the new sock API an implementation of the Simple Time Network Protocol
> (SNTP) was also introduced, allowing for time synchronization between nodes.
> New platforms include the Arduino Uno, the Arduino Duemilanove, the Arduino
> Zero, SODAQ Autonomo, and the Zolertia remote (rev. B).
> The most significant bug fix was done in native which led to a significantly
> more robust handling of ISRs and now allows for at least 1,000 native
> instances running stably on one machine.
> 
> About 263 pull requests with about 398 commits have been merged since the last
> release and about 42 issues have been solved. 37 people contributed with code
> in 100 days. 1006 files have been touched with 166500 insertions and 26926
> deletions.
> 
> You can download the RIOT release from Github by cloning the
> repository [1] or by
> downloading the tarball [2], and look up the release notes for further
> details [3].
> 
> Thanks everyone for your contributions, discussions, testing efforts,
> and keep RIOTing!
> 
> Kind regards and wishing you a great weekend,
> Martine
> 
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2016.10
> [2] https://github.com/RIOT-OS/RIOT/archive/2016.10.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/master/release-notes.txt
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
panic("IRQ, you lose...");
linux-2.2.16/arch/mips/sgi/kernel/indy_int.c


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

Re: [riot-devel] L2 Netstats

[Oleg Hahm]

Hi Carsten!

On Tue, Nov 01, 2016 at 04:10:01PM +0100, Carsten Bormann wrote:
> Please have a look at RFC7388 when doing this:
> 
>      Definition of Managed Objects for IPv6 over Low-Power Wireless
>      Personal Area Networks (6LoWPANs). J. Schoenwaelder, A. Sehgal, T.
>      Tsou, C. Zhou. October 2014. (Format: TXT=53451 bytes) (Status:
>      PROPOSED STANDARD) (DOI: 10.17487/RFC7388) 
> 
> The writing on the package says its SNMP, but the important thing is the
> definition of the counters, which have wider applicability.

That makes a lot of sense. Should have thought of this myself...

Thanks!

Cheers,
Oleg

-- 
/* Fuck.  The f-word is here so you can grep for it :-)  */
linux-2.4.3/include/asm-mips/mmu_context.h


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

Re: [riot-devel] bitfeilds

[Oleg Hahm]

Hi Martine!

On Thu, Oct 27, 2016 at 01:35:21PM +0200, Martine Lenders wrote:
> >> As example I was able to save several 100 bytes of ROM when removing the
> >> named bitfield use from the samr21s peripheral drivers.
> >
> >
> I don't know about your specific code, but I was able to show, that a
> bitfield actually *saves* ROM [1].

In your example the variables were not volatile.

Cheers,
Oleg
-- 
printk("Illegal format on cdrom.  Pester manufacturer.\n"); 
linux-2.2.16/fs/isofs/inode.c


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

Re: [riot-devel] Coding conventions amendment

[Oleg Hahm]

Hi Ludwig!

On Fri, Oct 14, 2016 at 12:26:19PM +0200, Ludwig Knüpfer wrote:
> Am 14. Oktober 2016 10:04:07 MESZ, schrieb Oleg Hahm <oliver.h...@inria.fr>:
> >On Fri, Oct 14, 2016 at 09:13:50AM +0200, Ludwig Knüpfer wrote:
> >> In general it is safer to explicate the integer width. As RIOT is
> >> targeted at 32 bit architectures,
> >
> >I object!
> 
> With what exactly?

With your last (half a) sentence I quoted. RIOT is IMO explicitly not
targeted only for 32-bit architectures. That's one thing that distinguishes
RIOT from many other OSs in this area.

Cheers,
Oleg
-- 
printk(KERN_WARNING MYNAM ": (time to go bang on somebodies door)\n");
linux-2.6.6/drivers/message/fusion/mptctl.c


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

Re: [riot-devel] Coding conventions amendment

[Oleg Hahm]

Hi Kees!

On Fri, Oct 14, 2016 at 08:05:51AM +0200, Kees Bakker wrote:
> On 13-10-16 22:42, Kaspar Schleiser wrote:
> > On 10/13/2016 09:43 PM, Kees Bakker wrote:
> > > > > Does anybody object to adding this to the coding
> > > > > > > conventions explicitly?
> > > > > What about `size_t`?
> > > +1 for size_t
> > Well, any convention would need careful wording.
> > 
> > ```
> > for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) {
> > if(try()) break;
> > }
> > ```
> > 
> > ... cannot blindly by convention converted to size_t as loop variable.
> 
> Of course not.
> But I believe the question was more, in case of an unsigned type,
> should we use "unsigned int" or size_t. In that case I would go for size_t.

No, the initial question was whether we should recommend (unsigned) int (or
(s)size_t) as loop iterator variable types.

Cheers,
Oleg
-- 
printk(KERN_WARNING "%s: Thanks, I feel much better now!\n", dev->name);
linux-2.6.6/drivers/net/de620.c


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

Re: [riot-devel] Coding conventions amendment

[Oleg Hahm]

Hi Ludwig!

On Fri, Oct 14, 2016 at 09:13:50AM +0200, Ludwig Knüpfer wrote:
> In general it is safer to explicate the integer width. As RIOT is targeted
> at 32 bit architectures,

I object!

Cheers,
Oleg
-- 
rio_dprintk (RIO_DEBUG_ROUTE, "LIES! DAMN LIES! %d LIES!\n",Lies);
linux-2.6.6/drivers/char/rio/rioroute.c


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

Re: [riot-devel] Coding conventions amendment

[Oleg Hahm]

Hi Martin!

On Wed, Oct 12, 2016 at 04:52:37PM +0200, Landsmann, Martin wrote:
> > On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote:
> > > Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm 
> > > <oliver.h...@inria.fr>:
> > > > as far I'm concerned it has been an undocumented coding convention so 
> > > > far
> > > > to use `int` or `unsigned int` for iterator variables in a loop instead 
> > > > of
> > > > fixed width integer types. Does anybody object to adding this to the 
> > > > coding
> > > > conventions explicitly?
> > > What about `size_t`?
> > I don't see a reason against `size_t` - but also no good reason that speaks
> > for it. What's the rationale?
> size_t is suited best to be used for iterating array indices and never
> overflow holding them [1].
> 
> [1] http://stackoverflow.com/a/2550799

Sorry, I don't get this. Can you elaborate?

Cheers,
Oleg
-- 
printk(KERN_WARNING MYNAM ": (time to go bang on somebodies door)\n");
linux-2.6.6/drivers/message/fusion/mptctl.c


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

Re: [riot-devel] Coding conventions amendment

[Oleg Hahm]

Hi!

On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote:
> Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm <oliver.h...@inria.fr>:
> >as far I'm concerned it has been an undocumented coding convention so far
> >to use `int` or `unsigned int` for iterator variables in a loop instead of
> >fixed width integer types. Does anybody object to adding this to the coding
> >conventions explicitly?
> 
> What about `size_t`?

I don't see a reason against `size_t` - but also no good reason that speaks
for it. What's the rationale?

Cheers,
Oleg
-- 
printk(KERN_WARNING "Warning: defective CD-ROM (volume sequence
number). Enabling \"cruft\" mount option.\n");
linux-2.2.16/fs/isofs/inode.c


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

Re: [riot-devel] BIN FILES

[Oleg Hahm]

Hi Ilias!

On Fri, Oct 07, 2016 at 03:51:48PM +0200, Ilias Seitanidis wrote:
> The problem is that I have a board based on samr21 but there is no edbg usb
> port, on the datasheet it mentions only
> reprogramming using a usb pen drive and a .bin file, I know nothing about
> the bootloader.

In this case, Joakim's advice should work. I think a similar trick is used for
the mbed_lpc1768.

Cheers,
Oleg
-- 
Yo mamma is so fat that she sat on a binary tree and made it a linked list in
constant time.


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

Re: [riot-devel] BIN FILES

[Oleg Hahm]

Hi Ilias!

On Fri, Oct 07, 2016 at 03:29:38PM +0200, Ilias Seitanidis wrote:
> Is it possible to create a bin file, which includes everything and then
> flash the .bin file
> on the board? (From what I've seen RIOT OS doesn't support this, right)

What exactly do you mean by ".bin" file? By default RIOT produces an ELF [1] 
file
for most platforms that contain the full binary that is flashed onto the
device.

Cheers,
Oleg

[1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
-- 
Chuck Norris doesn't do TCP handshake - he does TCP roundhouse-kick to initiate
the connection.


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

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Oct 5, 2016 2pm - 3pm (RIOT Events)

[Oleg Hahm]

Hi!

Sorry, couldn't make it, but some comments/questions:

On Wed, Oct 05, 2016 at 03:16:11PM +0200, Martine Lenders wrote:
>* How to prevent server problems we had at the weekend?
>   * downloads.riot-os.org was moved from kupfer to Kaspar's
> server due to power outage at FU
>* => Kaspar became single point of failure
>* Solutions:
>   * More people access to kupfer
>* Move to server at HAW (smlng can grant access to other people)
>* More people access to Kaspar's server?

From my point of view, the most important view is getting rid of this single
point of failure - independent if it is hosted at FUB, HAW or Hetzner. We
should have at least one fallback server.

>* Simon plans to rework GNRC TCP in the extended future (at Hack'n'ACKs?)

Can't we first merge the current solution ASAP and then do the rework?

Cheers,
Oleg
-- 
I’d tell you an UDP joke but you might not get it.  Also, I have a TCP joke.
I’ll keep telling it until you get it.


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

Re: [riot-devel] MRF24J40 radio module driver

[Oleg Hahm]

Hey Alex!

On Tue, Sep 06, 2016 at 08:48:13AM +0200, Alexander Aring wrote:
> > In case netopt is "NETOPT_SRC_LEN" and the value is 
> > "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets 
> > the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.
> > 
> > https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173
> >
> 
> I don't know why this goes down through the driver layer. The address
> filter doesn't need such information if you use as source address long
> or short.
> 
> For me it's unclear for what this sourc_len really is made for. I would
> suggest to use the best address setting which do the most smallest
> payload. Sure, there exists situation to overwrite such setting - but
> this should be done not as an interface setting.

Maybe I miss something, but how should the driver know which L2 address format
is expected at the receiver's side?

Cheers,
Oleg
-- 
HARDFAIL("Not enough magic.");
linux-2.4.0-test2/drivers/block/nbd.c


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

Re: [riot-devel] Communication among running RIOT board (native) and unix application

[Oleg Hahm]

Hi Nazmul, hi Michael!

On Wed, Aug 31, 2016 at 09:46:23AM +0200, Michael Frey wrote:
> Am Mi, 31.08.2016, 02:02, schrieb Nazmul Alam:
> > I am new to RIOT and trying to run it in native system. I would like to
> > know if it is possible to add another tap interface to the bridge to
> > monitor two native application's packet transaction and their contents?
> 
> have you looked into des-virt? Have you also checked out the tutorials [1]
> at the wiki, such as [1].

There's also a basic documentation available in the gnrc_networking example:
https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_networking/README.md

> > I want to communicate with an ipv4 based socket application with one of
> > the
> 
> To my best knowledge there is no IPv4 support in RIOT (yet).

In theory lwip, which is available as a package in RIOT, has support for IPv4,
but in practise I think no one has every tested this in RIOT.

Cheers,
Oleg
-- 
Unix is user friendly... its just selective about who its friends are.


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

Re: [riot-devel] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

[Oleg Hahm]

Okay, sorry, I was to fast with my complaint. ;-)

On Tue, Aug 30, 2016 at 04:17:33PM +0200, Oleg Hahm wrote:
> Hi,
> 
> is it only me who cannot find it or is there something missing here?
> 
> Cheers,
> Oleg
> 
> On Tue, Aug 30, 2016 at 04:10:19PM +0200, Martine Lenders wrote:
> > Hi Baptiste,
> > 
> > 
> > 2016-08-30 16:01 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> > > Thanks Martine,
> > > The issue you mentioned seems to be different.
> > >
> > > Did you see the neighbor discovery implementation of OpenThread? How
> > > your new implementation will be able to dicuss with OpenThread
> > > implementation?
> > >
> > > Cheers,
> > >
> > > 2016-08-29 19:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> > >> Hi,
> > >> can you check if this is https://github.com/RIOT-OS/RIOT/issues/5467?
> > >>
> > >>> Why or how can a node be removed from ncache? Why the node does not
> > >> automatically reconnect with BR?
> > >>
> > >> As the implementer of the neighbor discovery I can say this: because
> > >> the neighbor discovery is sh** ;-). It was written in a haste and has
> > >> a lot of design flaws. I'm working on a replacement (see
> > >> https://github.com/RIOT-OS/RIOT/issues/5704, happy to hear your
> > >> thoughts ;-)), but sadly I did not find some time to put heavy
> > >> implementation efforts into this yet (hopefully in autumn though, so
> > >> we have something for the October release, fingers crossed).
> > >>
> > >> Thanks for reporting and kind regards,
> > >> Martines
> > >>
> > >> 2016-08-29 17:54 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> > >>> Hi,
> > >>> I'm using two SAMR21, one with BR (on A) and the other (on B) with
> > >>> gnrc_networking example.
> > >>> I'm on April release.
> > >>> Switch on A (border router) then switch on B, I'm able to send UDP
> > >>> message from Linux to 2001:db8 address of B.
> > >>> If I try to send lot of data (every 100ms), it works for a while and
> > >>> then B does not receive message anymore. After I see it failed, I
> > >>> stopped the loop sending UDP message, I checked on BR and 2001:db8
> > >>> address of B was not here anymore. I can ping B with fe80:: address on
> > >>> iface 6 but can't with 2001:db8.
> > >>>
> > >>> Why or how can a node be removed from ncache? Why the node does not
> > >>> automatically reconnect with BR?
> > >>>
> > >>> Cheers
> > >>>
> > >>> --
> > >>> Baptiste
> > >>> ___
> > >>> 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
> > >
> > >
> > >
> > > --
> > > Baptiste
> > > ___
> > > 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
> 
> -- 
> The problem with token ring jokes is you need to wait your turn to laugh



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


-- 
printk(" Speed now 1x");/* Pull my finger! */
linux-2.6.6/drivers/cdrom/mcd.c


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

Re: [riot-devel] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

[Oleg Hahm]

Hi,

is it only me who cannot find it or is there something missing here?

Cheers,
Oleg

On Tue, Aug 30, 2016 at 04:10:19PM +0200, Martine Lenders wrote:
> Hi Baptiste,
> 
> 
> 2016-08-30 16:01 GMT+02:00 Baptiste Clenet :
> > Thanks Martine,
> > The issue you mentioned seems to be different.
> >
> > Did you see the neighbor discovery implementation of OpenThread? How
> > your new implementation will be able to dicuss with OpenThread
> > implementation?
> >
> > Cheers,
> >
> > 2016-08-29 19:56 GMT+02:00 Martine Lenders :
> >> Hi,
> >> can you check if this is https://github.com/RIOT-OS/RIOT/issues/5467?
> >>
> >>> Why or how can a node be removed from ncache? Why the node does not
> >> automatically reconnect with BR?
> >>
> >> As the implementer of the neighbor discovery I can say this: because
> >> the neighbor discovery is sh** ;-). It was written in a haste and has
> >> a lot of design flaws. I'm working on a replacement (see
> >> https://github.com/RIOT-OS/RIOT/issues/5704, happy to hear your
> >> thoughts ;-)), but sadly I did not find some time to put heavy
> >> implementation efforts into this yet (hopefully in autumn though, so
> >> we have something for the October release, fingers crossed).
> >>
> >> Thanks for reporting and kind regards,
> >> Martines
> >>
> >> 2016-08-29 17:54 GMT+02:00 Baptiste Clenet :
> >>> Hi,
> >>> I'm using two SAMR21, one with BR (on A) and the other (on B) with
> >>> gnrc_networking example.
> >>> I'm on April release.
> >>> Switch on A (border router) then switch on B, I'm able to send UDP
> >>> message from Linux to 2001:db8 address of B.
> >>> If I try to send lot of data (every 100ms), it works for a while and
> >>> then B does not receive message anymore. After I see it failed, I
> >>> stopped the loop sending UDP message, I checked on BR and 2001:db8
> >>> address of B was not here anymore. I can ping B with fe80:: address on
> >>> iface 6 but can't with 2001:db8.
> >>>
> >>> Why or how can a node be removed from ncache? Why the node does not
> >>> automatically reconnect with BR?
> >>>
> >>> Cheers
> >>>
> >>> --
> >>> Baptiste
> >>> ___
> >>> 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
> >
> >
> >
> > --
> > Baptiste
> > ___
> > 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

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


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

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 30, 2016 5pm - 10pm (RIOT Events)

[Oleg Hahm]

Hi Martine,

I'm still in Dagstuhl the whole week.

Cheers,
Oleg

On Tue, Aug 30, 2016 at 03:15:27PM +0200, Martine Lenders wrote:
> Hi,
> will anyone except myself be at FU Berlin tonight?
> 
> Cheers,
> Martine
> 
> Am 29.08.2016 5:00 nachm. schrieb "Google Calendar" <
> calendar-notificat...@google.com>:
> 
> > more details »
> > 
> > Hack'n'ACK
> >
> > *When*
> > Tue Aug 30, 2016 5pm – 10pm Berlin
> >
> > *Where*
> > FU Berlin; HAW Hamburg (map
> > )
> >
> > *Calendar*
> > RIOT Events
> >
> > *Who*
> > •
> > Martine Lenders - creator
> >
> > Invitation from Google Calendar 
> >
> > You are receiving this email at the account peterschme...@gmail.com
> > because you are subscribed for notifications on calendar RIOT Events.
> >
> > To stop receiving these emails, please log in to https://www.google.com/
> > calendar/ and change your notification settings for this calendar.
> >
> > Forwarding this invitation could allow any recipient to modify your RSVP
> > response. Learn More
> > .
> >
> > ___
> > 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


-- 
The problem with TCP jokes is that people keep retelling them slower until you
get them.


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

Re: [riot-devel] RFC: development procedures

[Oleg Hahm]

Hi Martine!

On Fri, Aug 19, 2016 at 10:53:49PM +0200, Martine Lenders wrote:
> Oleg Hahm wrote:
> > Yes, it takes more time, but just a few seconds if the commit messages are
> sensible. I never use autosquashing.
> 
> You should try it, its REEAAALLY convenient.

I did some time ago and couldn't see a big advantage and prefer meaningful
commit messages.

Cheers,
Oleg
-- 
panic("Halt failed!");
linux-2.6.6/arch/sparc/kernel/process.c


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

Re: [riot-devel] RFC: development procedures

[Oleg Hahm]

Hi,

On Fri, Aug 19, 2016 at 05:54:07PM +0200, Martine Lenders wrote:
> 2016-08-19 17:25 GMT+02:00 Kaspar Schleiser <kas...@schleiser.de>:
> > On 08/19/2016 05:15 PM, Oleg Hahm wrote:
> > > Hence, I would propose to somehow reference the addressed
> > > comment in the commit message. What do you think?
> >
> > That would rule out --fixup commits (and thus automatic rebasing). "git
> > commit --squash" allows adding to the commit message, but the commit
> > subject stays the same, so in order to improve things, one would have to
> > unfold the whole message in git's PR overview
> >
> 
> Not necessarily. I would put such links to comments in the commit body
> anyway and that is ignored by --autosquash.

hm, that makes it rather inconvenient to review - particular with the "new"
shitty GitHub UI.
 
> > Actually, I've never found a big advantage in automatic rebasing. If you
> > specify both, the addressed comment and the corresponding commit in the
> > commit
> > message, interactive rebasing can be done in no time.
> >
> 
> Well you still have to read and compare every single commit, which
> --autosquash just takes a way. So you still need way more time. ;-)

Yes, it takes more time, but just a few seconds if the commit messages are
sensible. I never use autosquashing.

Cheers,
Oleg
-- 
panic("bad_user_access_length executed (not cool, dude)");
linux-2.0.38/kernel/panic.c


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

Re: [riot-devel] RFC: development procedures

[Oleg Hahm]

Hi!

On Fri, Aug 19, 2016 at 05:25:32PM +0200, Kaspar Schleiser wrote:
> On 08/19/2016 05:15 PM, Oleg Hahm wrote:
> > Hence, I would propose to somehow reference the addressed
> > comment in the commit message. What do you think?
> 
> That would rule out --fixup commits (and thus automatic rebasing). "git
> commit --squash" allows adding to the commit message, but the commit
> subject stays the same, so in order to improve things, one would have to
> unfold the whole message in git's PR overview.

Actually, I've never found a big advantage in automatic rebasing. If you
specify both, the addressed comment and the corresponding commit in the commit
message, interactive rebasing can be done in no time.

A potential other solution would be to use something like Gerrit, but I guess
no one here wants this. ;-)

Cheers,
Oleg
-- 
The best thing about script jokes is that they start with a bang.


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

[riot-devel] RFC: development procedures

[Oleg Hahm]

Dear reviewing IoTlers,

looking at https://github.com/RIOT-OS/RIOT/pull/5758, I just realized that our
convention to add squash commits while a PR is under review may need an
amendment. If all commits that addresses a certain comment and are meant for
squashing have a non-speaking commit message (see linked PR), then it gets
more time-consuming for the reviewer to map a commit to a certain
review-reaction. Hence, I would propose to somehow reference the addressed
comment in the commit message. What do you think?

Cheers,
Oleg
-- 
printk(KERN_WARNING MYNAM ": (time to go bang on somebodies door)\n");
linux-2.6.6/drivers/message/fusion/mptctl.c


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

Re: [riot-devel] Fragmentation support in IP

[Oleg Hahm]

Hi Adeel,

On Thu, Aug 18, 2016 at 10:45:40PM +, Adeel Mohammad Malik wrote:
> We don't want to use CoAP as we are working with ICN (Information Centric
> Networking) protocols.

have you checked if fragmentation in CCN-lite works and would serve your
needs?

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


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

Re: [riot-devel] conn f2f (+ remote) meeting

[Oleg Hahm]

Thanks a lot!

On Thu, Aug 18, 2016 at 08:25:50AM +0200, Martine Lenders wrote:
> Hi,
> 
> 2016-08-17 19:28 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>:
> 
> > Hey folks,
> >
> > On Mon, Aug 15, 2016 at 04:11:48PM +0200, Martine Lenders wrote:
> > > as promised: here is the agenda for the meeting next Wednesday:
> > > http://yourpart.eu/p/netapp-api-riot
> >
> > thanks for the protocol, but is a bit hard to follow as a non-attendee.
> > Could
> > anyone come up with a short summary and, in case you concluded on a
> > particular API, could present how it should look like?
> 
> 
> already reworked it to a more readable form (just waited for some comments
> by the attendees) [1]
> 
> TL;DR:
> * reworked API will be called sock not conn to keep them distinguishable
> when talking about it / porting it
> * UDP/IP will have a somewhat reduced function set (convenience functions
> are dropped)
> * TCP will have a queue type for listening
> * create functions for all will receive a flags parameter so options that
> need to be done before binding can be passed
> 
> For reference I will adapt #5533 today
> 
> [1]
> https://github.com/RIOT-OS/RIOT/wiki/Application-Layer-API-Meeting-on-August-17,-2016
> 
> Cheers,
> Martine
> 
> Application Layer API Meeting 1
> ===
> 
> Agenda
> --
> 1. Agenda Bashing
> 2. Goals and Priorities
> 3. Naming of the API
> 4. Detailed API-discussion:
> 1. IP-based transport layer with datagram-based communication (IP raw /
> UDP)
> 2. IP-based transport layer with sequence-based communication (TCP)
> 5. Future extension
> 1. Asynchronous event handling: External vs. native support
> 2. Options
> 3. Per packet configuration
> 
> Meeting Details
> ---
> ### Attendees
> * Alexander Aring [eintopf]
> * Cenk Gündoghan
> * Kaspar Schleiser
> * Martine Lenders (Chair)
> * Peter Kiezmann
> * Simon Brummer
> 
> ### Protocol
> * Peter
> * Simon
> 
> Goals / Priorities
> --
> 1. No need for dynamic memory allocation
> 2. User friendliness
> 3. Simplicity
> 4. Efficiency (at both front- and backend)
> 5. Easy to implement for network stacks / portability
> 
> Naming of the API
> -
> * Pro `conn:
> - Name was picked to differ from the old sockets because it isn't socket
> * Con `conn`:
> - `conn` basically behaves like sockets (just look at the
> function-calls)
> - New-comers might search for "something like sockets" anyway
> - Name change would show API change better and ultimately would be less
>   confusing for users of `conn`
> * Result: `sock` as name for the new API
> * Side discussion: Documenting API changes
> - Wiki does not work, because it is forgotten after creation
> - Documentation via a dedicated README file is better
> 
> Detailed API-discussion
> ---
> ### IP-based transport layer with datagram-based communication (IP raw /
> UDP)
> - [Reference API][conn_udp]
> - `sock_udp_create`/`sock_udp_close` good as is
> - Getter (`sock_udp_get_local`/`sock_udp_get_remote`) stay because they
> don't
>   hurt and are needed for socket wrapper implementation
> - Setter: easier and more convenient to create new `sock` instead
> - `sock_udp_recv` and `sock_udp_recvfrom`:
> * Order of parameters of `sock_udp_recvfrom` confusing with that name
> * Static inline in API definition not nice
> * Result:
> + original `sock_udp_recv` should be removed
> + `sock_udp_recvfrom` renamed to `sock_udp_recv`
> - `sock_udp_send` and `sock_udp_sendto`:
> * There are three sensible use-cases for `sock_udp_sendto`
> 1. `sock != NULL`, `sock` is connected, and `remote == NULL`
> 2. `sock != NULL`, `sock` is connected, and `remote != NULL`
> 3. `sock == NULL` and `remote != NULL`
> * Currently only convenient function for 1., why not for 3.?
> * Also again: static inline in API definition
> * Result:
> + original `sock_udp_send` should be removed
> + `sock_udp_sendto` renamed to `sock_udp_send`
> 
> ### IP-based transport layer with sequence-based communication (TCP)
> - [Reference API][conn_tcp]
> - [Simon wants a `sock_tcp_listen` function][conn_tcp_listen]
> - Kaspar: two object types requiered
> - One representing a connection,
> - One representing a listening socket
> - split `sock_tcp_create` and `sock_tcp_close`:
> 
> ~~
> {.c

Re: [riot-devel] conn f2f (+ remote) meeting

[Oleg Hahm]

Hey folks,

On Mon, Aug 15, 2016 at 04:11:48PM +0200, Martine Lenders wrote:
> as promised: here is the agenda for the meeting next Wednesday:
> http://yourpart.eu/p/netapp-api-riot

thanks for the protocol, but is a bit hard to follow as a non-attendee. Could
anyone come up with a short summary and, in case you concluded on a
particular API, could present how it should look like?

Cheers,
Oleg
-- 
printk("; corrupted filesystem mounted read/write - your computer 
will explode within 20 seconds ... but you wanted it so!\n");
linux-2.4.3/fs/hpfs/super.c


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

Re: [riot-devel] Disable 15.4 Acknowledgements

[Oleg Hahm]

Hi Simon!

On Tue, Aug 09, 2016 at 04:44:40PM +0200, simon wrote:
> netopt_enable_t opt = NETOPT_DISABLE;
> gnrc_netif_get(ifs);
> gnrc_netapi_set(ifs[0], NETOPT_AUTOACK, 0, , sizeof(opt));
> gnrc_netapi_set(ifs[0], NETOPT_ACK_REQ, 0, , sizeof(opt));
> 
> 
> Did the trick. So there is a way to disable acknowledgements.

Have you checked if this actually works (i.e. no more ACKs are sent)?

If yes, cool and sorry for my wrong statement.

Cheers,
Oleg
-- 
gur orfg guvat nobhg EBG13 wbxrf vf, rirelbar unf gb qvt hc gurve 20 lrne byq
pbairegref


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

Re: [riot-devel] qemu-i386 port

[Oleg Hahm]

Hi Ludwig!

On Tue, Aug 09, 2016 at 02:30:25PM +0200, Ludwig Knüpfer wrote:
> Without any further insights I would say your case is different because the
> board is actively maintained, used, and can be bought.
> In the case of the FU boards I had in mind (msb430*) none of these points is 
> true.

While I agree with your assessment, I don't think we should drop support for
MSB430 platforms. First, we have plenty of them in Berlin and Hamburg and I
will happily lend them to anyone asking for it. Second, they are (or at least
were) used in other academic institutes in WSN area. Finally, they are very
similar to widely used platforms such as TelosB or WSN430 and the additional
maintenance effort is really small. However, we definitely should try harder
to get a better support for MSP430 platforms in general.

Cheers,
Oleg
-- 
printk("NULL POINTER IDIOT\n");
linux-2.6.6/drivers/media/dvb/dvb-core/dvb_filter.c


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

Re: [riot-devel] Disable 15.4 Acknowledgements

[Oleg Hahm]

Hi Simon!

On Tue, Aug 09, 2016 at 02:33:56PM +0200, simon wrote:
> Currently I am testing my TCP implementation between two samr21 Boards
> and a Raspberry Pi as sniffing Probe in between.
> 
> My measured network dump contains a few unexpected retransmissions and
> i am unable to distinguish between retransmissions caused by 15.4 and
> retransmissions caused by TCP. Is there a way to disable the 15.4
> acknowledgement and retransmission mechanism?

IIRC auto acknowledgement can currently not be disabled with the at86rf2xx
driver, but you can set the retransmissions to zero. You can do this either
using the shell:
 
 ifconfig 7 set retrans 0

or directly via netapi:

 gnrc_netapi_set(CCNLRIOT_NETIF, NETOPT_CSMA_RETRIES, 0, 0, sizeof(uint8_t));

Cheers,
Oleg
-- 
Chuck Norris doesn't do TCP handshake - he does TCP roundhouse-kick to initiate
the connection.


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

Re: [riot-devel] qemu-i386 port

[Oleg Hahm]

Hey!

On Tue, Aug 09, 2016 at 02:06:07PM +0200, Ludwig Knüpfer wrote:
> I'm all for cleaning up stale boards, especially I'd they are as hard to
> obtain as for example the FU boards.

Well, hopefully this situation is about to change once the RasPi
infrastructure is in place.

Cheers,
Oleg
-- 
Yo mamma is so fat that she sat on a binary tree and made it a linked list in
constant time.


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

Re: [riot-devel] qemu-i386 port

[Oleg Hahm]

Hi!

On Tue, Aug 09, 2016 at 10:34:19AM +0200, Martine Lenders wrote:
> we now have the third person wondering about the qemu-i386 port.

For the record: I count only two.

Otherwise: +1 for the proposal.

Cheers,
Oleg

P.S. Should we drop support for the Spark as well?
-- 
I'm working on a bittorrent joke, but I only have about 30% and nobody's
seeding!


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

Re: [riot-devel] Απ: Problem with "make" -lm missing.

[Oleg Hahm]

Hi!

On Tue, Aug 09, 2016 at 08:27:04AM +, MiTsArAs Jimaras wrote:
> Now I have another problem!
> 
> I compile on native board, and everything is alright.
> 
> When I am trying to compile on qemu-i386, it seems to start, but I get no
> results.

Please note that support for i386 is rather rudimentary. Any particular reason
you want to use this platform?

Cheers,
Oleg
-- 
panic("Aarggh: attempting to free lock with active wait queue - shoot Andy");
linux-2.0.38/fs/locks.c


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

Re: [riot-devel] Απ: Make bootable .elf file!

[Oleg Hahm]

Hi Loïc!

On Thu, Jul 28, 2016 at 08:49:54PM +0200, astralien3000 wrote:
> I am not sure of what you are doing with qemu, but, even if RIOT is called
> an OS, it can't be executed on i386 without a mainstream OS (=Linux,
> Windows, ...). Indeed, the "native" implementation is not a bootloader.

Not quite true: there is support for RIOT on QEMU-i385 [1]. However, this
board is not really well maintained and rather rudimentary. So, in the end one
would indeed rather use native instead.

Cheers,
Oleg

[1] https://github.com/RIOT-OS/RIOT/tree/master/boards/qemu-i386
-- 
printk(KERN_WARNING MYNAM ": (bad VooDoo)\n");
linux-2.6.6/drivers/message/fusion/mptctl.c


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

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)

[Oleg Hahm]

Hey Paco!

On Wed, Jul 27, 2016 at 02:10:41PM +0200, Francisco Javier Acosta Padilla wrote:
> Not in my knowledge… Do you want to discuss something special? As the
> release is taking place I don’t know about the availability of people to
> discuss.

No reason for meeting from my side.

Cheers,
Oleg
-- 
The four hard things in CS are cache invalidation, naming, and off-by-one
errors.


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

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)

[Oleg Hahm]

Hi Peter!

On Wed, Jul 27, 2016 at 02:09:22PM +0200, Peter Kietzmann wrote:
> as always you can find the link to an etherpad here:
> 
> https://github.com/RIOT-OS/RIOT/wiki/Meetings

Thanks! Didn't know that there was a permanent link. (Or I forgot.)

> under point "Agenda for the next virtual meeting". There is not topic on the
> agenda so we skip this meeting.

+1

Cheers,
Oleg
-- 
The worst thing about Perl jokes is that next morning you can't understand why
they seemed so funny.


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

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)

[Oleg Hahm]

Dear release-preparing IOTlers,

do we have an Etherpad with an agenda for today's meeting?

If not, do we need one?

Cheers,
Oleg

On Tue, Jul 26, 2016 at 12:00:07PM +, Google Calendar wrote:
> This is a notification for:
> 
> Title: Biweekly virtual meeting
> Developer discussions that will only happen if a proposed agenda exists.
> Some instructions and a link to the agenda can be found in the RIOT wiki
> (https://github.com/RIOT-OS/RIOT/wiki/Meetings). Remote participation will
> be provided.
> When: Wed Jul 27, 2016 2pm – 3pm Berlin
> Calendar: RIOT Events
> Who:
> * Ludwig Ortmann - creator
> 
> Event details: 
> https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA3MjdUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn
> 
> Invitation from Google Calendar: https://www.google.com/calendar/
> 
> You are receiving this email at the account peterschme...@gmail.com because
> you are subscribed for notifications on calendar RIOT Events.
> 
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings for
> this calendar.
> 
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn more at
> https://support.google.com/calendar/answer/37135#forwarding

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


-- 
panic("aha1740.c"); /* Goodbye */
linux-2.2.16/drivers/scsi/aha1740.c


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

Re: [riot-devel] RE - Tutorial "How to port a radio module driver to RIOT OS"

[Oleg Hahm]

Hi Aaron!

On Wed, Jul 27, 2016 at 06:28:18AM +1200, Aaron Sowry wrote:
> > I'm really interested to this topic because i need to do it too for the
> > OpenMote board.
> 
> There's a fairly comprehensive tutorial on how to do this for the
> OpenMote here[1] already ;)
> 
> [1] https://github.com/RIOT-OS/RIOT/pull/5291

Maybe I miss something, but I was unable to find a tutorial in there.

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


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

Re: [riot-devel] Tutorial "How to port a radio module driver to RIOT OS"

[Oleg Hahm]

Hi Neo!

On Tue, Jul 26, 2016 at 06:38:33PM +0200, Neo wrote:
> I would like to start such a tutorial on the RIO-OS wiki. I think for most
> developers this will be more comfortable than reverse engineering or just
> reading the API list.

Cool! Many thanks for the initiative. I think this could be certainly a very
useful piece of documentation.

> Due to the fact that I'm not an "architect" of RIOT-OS I just will write
> down what I found out during my work.
> I hope that the main developers will take the time to make here some
> proof-reading and correct things which I misunderstood.

Sure. That's exactly the idea of a wiki. I can think of a couple of RIOT core
developers who would be happy to help, proofread and extend this tutorial.

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


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

Re: [riot-devel] C.H.I.P

[Oleg Hahm]

Hi!

On Wed, Jul 20, 2016 at 10:36:09AM +0200, Emmanuel Baccelli wrote:
> at first sight Linux can run on C.H.I.P.
> So why not use Linux?
> RIOT targets devices which cannot run Linux (or derivatives/equivalents).
> Hence: there are no plans to support CHIP

I added a point to the FAQ:
https://github.com/RIOT-OS/RIOT/wiki/FAQ#does-riot-supports-raspberry-pi

You could replace Raspberry PI with C.H.I.P. here.

@all: feel free to improve this answer or other parts of the FAQ.

Cheers,
Oleg
-- 
panic("Halt failed!");
linux-2.6.6/arch/sparc/kernel/process.c


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

Re: [riot-devel] [riot-maintainer] Feature freeze for upcoming release

[Oleg Hahm]

Dear maintainers

On Mon, Jul 11, 2016 at 02:31:33PM +0200, Francisco Javier Acosta Padilla wrote:
> We are about to focus on the next RIOT release. Feature freeze will take
> place at the end of the week (Sunday 17th July) and the plan is to get the
> 2016.10 release out by October 31st.

Two questions:
1.) What is the estimated release date for 2016.07?
2.) What is the real Feature Freeze deadline? ;-)

Cheers,
Oleg
-- 
"The funny thing about C jokes is when the null terminator is %s
?Ҿ?>Ӿ???.?7???WPw.k?o.p4???.?4h"


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

Re: [riot-devel] Skimpy make-do streaming of RIoT summit plenary

[Oleg Hahm]

+1

On Fri, Jul 15, 2016 at 09:35:06AM +0200, Emmanuel Baccelli wrote:
> Thanks Carsten!
> 
> On Jul 15, 2016 9:30 AM, "Carsten Bormann"  wrote:
> 
> >
> > https://hangouts.google.com/hangouts/_/bomthsflordmhfhplund2imm64e
> >
> > You cannot see the slides there; copies of the slides are slowly
> > gathering at http://www.tzi.de/~cabo/riot-summit/
> >
> > If you join the hangout, please send feedback to #riot=os
> > (irc.freenode.net).
> >
> > Grüße, Carsten
> > ___
> > 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


-- 
I'd make a joke about UDP, but I don't know if anyone's actually listening...


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

[riot-devel] 6LoWPAN GHC (RFC 7400)

[Oleg Hahm]

Hi,

if I remember correctly there was some discussion about implementing Generic
Header Compression for 6LoWPAN [1] in the past, but I don't remember the
outcome. Is anybody already working on this topic or planning to do so?

Cheers,
Oleg

P.S. In case anybody is interested: I have a (non-RIOT specific)
implementation in one of my repositories [2]. Caveats: (i) it's based on an
old version of the draft and (ii) I haven't implemented this myself so I
cannot say anything about the code quality.

[1] https://tools.ietf.org/html/rfc7400
[2] https://github.com/OlegHahm/ghc
-- 
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
linux-2.2.16/arch/sparc/kernel/traps.c


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

Re: [riot-devel] Question regarding CCN-lite and RIOT supported platforms

[Oleg Hahm]

Hi Adeel!

On Thu, Jun 30, 2016 at 10:08:06AM +, Adeel Mohammad Malik wrote:
> > >> Assuming I run CCN-lite directly on 802.15.4, how would I connect the
> > >> STM32F4Discovery board to a computer that acts as a gateway to the CCN
> > >> network?
> > >
> > > That's indeed an interesting question. I think the easiest solution would 
> > > be
> > > to either plug an Ethernet module to the Discovery Board or use ethos
> > > (ETHernet Over Serial) [2] to connect to the Gateway that run a CCN-lite
> > > client with two interfaces (one with an Ethernet socket pointing to the 
> > > RIOT
> > > node and one with an IP/UDP socket pointing to the rest of the world).
> 
> I am a bit confused here. Are you talking about running CCN-lite over
> Ethernet? And if I was to run CCN-lite over Ethernet would I not need an
> Ethernet module for which RIOT has a driver? There is an extension board
> (STM32F4DIS-BB) for the STM32F4Discovery board that provides an Ethernet
> jack. What I am not sure about though is whether there is driver support in
> RIOT for the Ethernet interface on STM32F4DIS-BB.

As far as I understand the STM32F4 comes already with integrated Ethernet
functionality and the STM32F4DIS-BB just provides the Ethernet jack (RJ45). So
far, there is AFAIK no driver for the Ethernet capabilities on the STM32F4,
but it shouldn't be too difficult(TM) to implement that, since there is
already a general Ethernet netdev2 interface.

> I was also thinking a bit about how easy it would be to do a similar thing
> but over 802.15.4 and not Ethernet. As Peter and you have pointed out, I
> could use wires to connect the Atmel at86rf2xx transceiver to the
> STM32F4Discovery board. The gateway side seems a bit problematic though. I
> could plug in an 802.15.4 dongle in a gateway device and run CCN-lite
> (without the RIOT OS) on the gateway. However, then CCN-lite should be able
> to run over 802.15.4. I assume that CCN-lite does not have support for that.

You're right: CCN-lite native only supports Ethernet, but I don't think it
should be very complicated to add this feature.

> One thing that could possibly be done here is to use a hardware platform of
> the scale of a Raspberry Pie that supports the RIOT OS for the gateway. Then
> I could run the CCN-lite + RIOT OS on that gateway and attach an 802.15.4
> transceiver to it to communicate with the STM32F4Discovery board on one hand
> and interface it via UDP/IP/Ethernet to the network side on the other. But
> this assumes that RIOT OS support relays nodes (not just end nodes) and can
> run on dual stack i.e. 802.15.4 on one side and UDP/IP/Ethernet on the
> other. Also in the list of supported platforms on the RIOT homepage I don’t
> see a platform (of the scale of Raspberry Pie) that can do this. Is RIOT
> supported on the Raspberry Pie?

RIOT does not run directly on the Raspberry Pi (although you could run RIOT
native on Pi hosted Linux). The Raspberry Pi is considered as out of scope for
RIOT. Basically, everything that runs Linux is considered out of scope.

You can either use Ethernet dongle for any sensor board and implement the
driver if needed, use Ethernet over serial (ethos) or connect a 802.15.4
dongle to the Pi.

Cheers,
Oleg

-- 
panic ("Splunge!");
linux-2.2.16/drivers/scsi/psi240i.c


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

Re: [riot-devel] about mqtt on riot os

[Oleg Hahm]

Hi Andy,

as far as I saw you were not yet subscribed to the mailing list, hence, I
forward you Michael's response. However, I suggest that you subscribe to the
list, too.

Cheers,
Oleg

P.S. In case I'm mistaken: sorry for the noise.

On Thu, Jun 23, 2016 at 11:16:35PM +0200, Michael Frey wrote:
> Hi Andy,
> 
> Am Do, 23.06.2016, 15:56, schrieb Andy Rosete:
> 
> > Hello my name is andy, Im from Spain and I'm studing a Informatic Master.
> > My work for the master degree is implement MQTT protocol on RIOT OS, i've
> > been searching information about it and i don't sure if that things was
> > implemented.
> 
> I'm working on a MQTT-SN client right now. While I've originally planned
> to be done with it some time ago, I've had only a limited amount of time
> to work on this. However, most things are done and need only to be tied
> together and tested. Currently, I hope to open a pull request before the
> RIOT summit in Mid-July so it can become hopefully part of the next RIOT
> release.
> 
> > I would ask if you have implemented it, in case of not, please could you
> > help me with information about where can i search or some advise.
> 
> I would suggest that we take this off-list since discussing the finer
> details of the MQTT-SN implementation and its differences to MQTT are
> probably not that much interesting for everybody else on this list. I'll
> get back to you in an "extra" mail by tomorrow.
> 
> Best,
>  Michael
> -- 
> Dipl.-Inf. (FH), M. Sc. Michael Frey
> Humboldt-Universität zu Berlin
> Department of Computer Science
> Rudower Chaussee 25
> 12489 Berlin, Germany
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
panic("Detected a card I can't drive - whoops\n");
linux-2.2.16/drivers/net/daynaport.c


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

Re: [riot-devel] Boards with MAC 802.15.4e

[Oleg Hahm]

Hi Alessandro,

On Mon, Jun 20, 2016 at 05:53:14PM +0200, ALESSANDRO NICOLI wrote:
> Between the RIoT's supported boards,  what are those that support the MAC
> 802.15.4e standard ?

in general each IEEE 802.15.4 capable transceiver can be used. However, I
would advise to use the at86rf2xx as present on iotlab-m3 or SAMR21-Xplained.

Cheers,
Oleg
-- 
The four hard things in CS are cache invalidation, naming, and off-by-one
errors.


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

Re: [riot-devel] OpenThread port: IEEE802.15 ACK

[Oleg Hahm]

Hi José!

On Thu, Jun 16, 2016 at 05:18:32PM +0200, Jose Alamos wrote:
> I'm porting the OpenThread stack to RIOT. I have hooks for sending and
> receiving frames and for transmision/reception "Done" signals (TransmitDone
> and ReceiveDone)
> 
> In their examples they are manually checking/sending IEEE802.15 ACK before
> calling the corresponding Done hook, but I'm not sure if I should do the
> same from RIOT. Are drivers in charge of handling these ACKs (so RIOT's
> TX_COMPLETE is triggered after receiving ACK)?
> 
> Basically I have to call the TransmitDone hook when the transmission is
> done, and that's only if the ACK is received.

That's dependent on the driver and (at least in principle) on its
configuration. For the at86rf2xx the current driver sends ACKs automatically
and the caller will get the TX_COMPLETE if an ACK was received (or
transmissions was broadcast).

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


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

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jun 1, 2016 2pm - 3pm (RIOT Events)

[Oleg Hahm]

Hi!

Do we have a pad for this meeting? If yes, is there anything on the agenda? If
no, does someone have a topic for the meeting? If no, let's skip this meeting.

Cheers,
Oleg

On Tue, May 31, 2016 at 12:00:02PM +, Google Calendar wrote:
> This is a notification for:
> 
> Title: Biweekly virtual meeting
> Developer discussions that will only happen if a proposed agenda exists.
> Some instructions and a link to the agenda can be found in the RIOT wiki
> (https://github.com/RIOT-OS/RIOT/wiki/Meetings). Remote participation will
> be provided.
> When: Wed Jun 1, 2016 2pm – 3pm Berlin
> Calendar: RIOT Events
> Who:
> * Ludwig Ortmann - creator
> 
> Event details: 
> https://www.google.com/calendar/event?action=VIEW=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA2MDFUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn
> 
> Invitation from Google Calendar: https://www.google.com/calendar/
> 
> You are receiving this email at the account peterschme...@gmail.com because
> you are subscribed for notifications on calendar RIOT Events.
> 
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings for
> this calendar.
> 
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn more at
> https://support.google.com/calendar/answer/37135#forwarding

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


-- 
The problem with a SQL security joke is that Sony don't get it.


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

Re: [riot-devel] arduino-uno support

[Oleg Hahm]

Hi!

First of all: I'm really excited about this. The atmega328p is a very widely
used MCU and having support for RIOT would be wonderful. Thanks for the effort
and definitely +100 for sharing with the community.

On Fri, May 13, 2016 at 09:04:03AM +0200, Alexandre Abadie wrote:
> I have one so I'll be able to give a try and test. As a side note, the
> atmega328p has very limited ressources (32KB flash, 2KB SRAM) so this will
> limit the use cases with RIOT (no network stack, etc).

Yes, it's true that this MCU has very limited resources and it will be
challenging to create a useful application. However, I think it can be
possible to run a stripped-down network application with RIOT even on this.
Without any code optimization a minimalistic GNRC application
(examples/gnrc_minimal) requires about 3kB on Z1 (MSP430/16 bit). Compiling
the same application for arduino-mega2560 requires about 1.8kB of RAM, but
without a radio driver (and thus, without allocating stack for the L2 thread).
Hence, we're already close!

Cheers,
Oleg

P.S. Of course, even if GNRC (or another network stack) fits on the device,
the challenge to leave space for a meaningful application remains. ;-)
-- 
The problem UDP jokes


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

[riot-devel] PowerProfiler

[Oleg Hahm]

Dear really-low-power IOTlers,

reading through https://github.com/RIOT-OS/RIOT/pull/2309 I stumbled across
Michael Andersen's PowerProfiler [1] and was literally shocked that such a
nice tool/setup has been gone unnoticed for so long. At least I was not aware
of this setup and checking with some other people on IM, it seems that I'm not
alone.

This looks like a really cool and promising solution to get an understanding
of the power consumption for RIOT applications. Great work, Michael!

Cheers,
Oleg

[1] https://github.com/PowerProfiler/TestApplications
-- 
panic("Yeee, unsupported cache architecture.");
linux-2.6.6/arch/mips/mm/cache.c


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

Re: [riot-devel] Bi-weekly meeting

[Oleg Hahm]

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?

[Oleg Hahm]

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

Re: [riot-devel] Add static library to Makefile

[Oleg Hahm]

Baptiste,

On Sat, Apr 02, 2016 at 05:25:46PM +0200, Baptiste Clenet wrote:
> Weird, Oleg, did you try to use the library? Could you include .h file
> which are inside .a library and use some functions. It was able to
> find the library .a but couldn't link with function inside the library

the libexample.a just contains one .o file with one function (`int my_add(int
a, int b);`, see
https://github.com/OlegHahm/miniature-dangerzone/blob/master/static_linked/main.c#L3).
This function gets linked and successfully called if you build the
application.

Cheers,
Oleg
-- 
panic("Yeee, unsupported cache architecture.");
linux-2.6.6/arch/mips/mm/cache.c


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

Re: [riot-devel] Add static library to Makefile

[Oleg Hahm]

Hi Baptiste!

On Wed, Mar 30, 2016 at 09:26:01AM +0200, Baptiste Clenet wrote:
> I tried to use
> APPDEPS +=  libexample.a
> Does not work

Strange, for me it works like charm:
https://github.com/OlegHahm/miniature-dangerzone/tree/master/static_linked

Cheers,
Oleg
-- 
/* When we have more time, we can teach the penguin to say 
 * "By your command" or "Activating turbo boost, Michael".
 */
linux-2.2.16/arch/sparc/prom/sun4prom.c


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

Re: [riot-devel] Add static library to Makefile

[Oleg Hahm]

Hi Kaspar!

On Wed, Mar 30, 2016 at 10:51:03AM +0200, Kaspar Schleiser wrote:
> On 03/30/2016 09:26 AM, Baptiste Clenet wrote:
> > I tried to use
> > APPDEPS +=  libexample.a
> > Does not work
> 
> Try copying it into the bin/$BOARD folder, then add
> "USEMODULE += libexample" to your makefile.

That sounds more like a workaround since you would have to copy it again after
every `make clean`. IMO APPDEPS should fit. Will investigate, why it doesn't
work.

Cheers,
Oleg
-- 
printk (KERN_DEBUG "Somebody wants the port\n");
linux-2.6.6/drivers/parport/parport_pc.c


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