Re: [riot-devel] About function pointers
Hey Kaspar! > But IMHO we should not take that experience (and yours from that former > employee) to dismiss anything involving function pointers or some kind of > object orientation, if it looks good in code and doesn't impose runtime > costs. Agreed. > E.g., I'd rather use const function pointers than macros... I couldn't agree more. Cheers, Oleg -- gur orfg guvat nobhg EBG13 wbxrf vf, rirelbar unf gb qvt hc gurve 20 lrne byq pbairegref pgpBrT_L6GiED.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing - This is just to state an opinion of a different kind :-)
Hi, On 02/20/15 13:50, Thomas C. Schmidt wrote: sorry to interrupt here: You are discussing the question whether Linux is available for more hardware than RIOT ??? No. We're discussing if developing proprietary products using RIOT is comparable to developing proprietary products using embedded Linux. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing - This is just to state an opinion of a different kind :-)
Hi guys, sorry to interrupt here: You are discussing the question whether Linux is available for more hardware than RIOT ??? Even though this discussion may be a nice amusing chat for tea time (imagining a 'native port' of Linux running as a RIOT Thread, RIOT on a CRAY Supercomputer, RIOT operating the fridge of the Space Shuttle), it seems completely irrelevant with respect to the subject "LGPL compliance testing". Instead of broadening the debate further and further, I would very much like to see this subject converge ... and vanish. If I remember correctly, we had a pretty convergent perspective about half a year ago ... and nothing new or relevant has sprung to my eyes since then. May be I miss important details ... but I'm actually more attached to moving forward than discussing in widest broadness. Cheers & happy weekend Thomas On 20.02.2015 13:35, Emmanuel Baccelli wrote: Hi Matthias, On Thu, Feb 19, 2015 at 11:47 PM, Matthias Waehlisch mailto:m.waehli...@fu-berlin.de>> wrote: Hi Kaspar, sorry for the silence! As you pointed out in your email, there are scenarios where the approach will not help due to technical reasons (and using a weird compiler might have technical reasons as well). You may consider these as irrelevant. But there is one aspect for sure in the IoT, the IoT is much more heterogenous compared to the current Internet. This is a crucial difference making the approach less suitable compared to developing for Linux, for example. For me the sentence "RIOT allows LGPL + proprietary source code at the same level of comfort compared to Linux" sounds like a cheap marketing slogan making clear that the persons are not aware of the IoT diversity. Linux runs on a wide variety of 32bit and 64bit hardware. RIOT aims to do the same on other (smaller) hardware, for a wide variety of 32bit, 16bit (and to some extent 8bit) platforms. At first sight, I don't see a huge difference here in terms of heterogeneity. How would you quantify/qualify this difference? Best Emmanuel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Matthias, On Thu, Feb 19, 2015 at 11:47 PM, Matthias Waehlisch < m.waehli...@fu-berlin.de> wrote: > Hi Kaspar, > > sorry for the silence! > > As you pointed out in your email, there are scenarios where the > approach will not help due to technical reasons (and using a weird > compiler might have technical reasons as well). You may consider these > as irrelevant. But there is one aspect for sure in the IoT, the IoT is > much more heterogenous compared to the current Internet. This is a > crucial difference making the approach less suitable compared to > developing for Linux, for example. > > For me the sentence "RIOT allows LGPL + proprietary source code at the > same level of comfort compared to Linux" sounds like a cheap marketing > slogan making clear that the persons are not aware of the IoT diversity. > > Linux runs on a wide variety of 32bit and 64bit hardware. RIOT aims to do the same on other (smaller) hardware, for a wide variety of 32bit, 16bit (and to some extent 8bit) platforms. At first sight, I don't see a huge difference here in terms of heterogeneity. How would you quantify/qualify this difference? Best Emmanuel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] About function pointers
Hi, On 02/20/15 08:01, Oleg Hahm wrote: A bit polemic: can't we use Java then and rely on a highly optimized (micro) JVM? ;) Maybe the question here is if we should concentrate on gcc and clang and keep "weird, esoteric, proprietary compilers that someone might use someday in an not-yet-thought-of use case" as they are - useless. Was this a vote for a function pointer based HAL or just a Torvalds-like reflex? If the former is the case, then I'm apparently the only one - counting the silent people on this topic as agreeing or not caring - against this approach. In this case I would advice to rethink and remodel the whole driver and HAL design. With the use of function pointers it could be made extremely more (pseudo) object-oriented what make many things much more convenient to implement. I remember that over-engineered HAL we invested a lot of work to get out of. ;) I don't vote to get back there. But IMHO we should not take that experience (and yours from that former employee) to dismiss anything involving function pointers or some kind of object orientation, if it looks good in code and doesn't impose runtime costs. E.g., I'd rather use const function pointers than macros... Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi, On 02/20/15 13:07, Emmanuel Baccelli wrote: Saying otherwise makes clear that the persons are not aware of the troubles embedded linux companies go through when developing proprietary devices using (L)GPLed linux + libraries. What do you mean by "proprietary device"? Routers, access points, media players, smartphones, ... Any device combining e.g., Linux with proprietary code. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, On Fri, Feb 20, 2015 at 12:24 PM, Kaspar Schleiser wrote: > Hey Matthias, > > On 02/19/15 23:47, Matthias Waehlisch wrote: > >>As you pointed out in your email, there are scenarios where the >> approach will not help due to technical reasons (and using a weird >> compiler might have technical reasons as well). You may consider these >> as irrelevant. But there is one aspect for sure in the IoT, the IoT is >> much more heterogenous compared to the current Internet. This is a >> crucial difference making the approach less suitable compared to >> developing for Linux, for example. >> > Interesting how technical reasons are the main point you've read out my > email. > > Let me correct myself. > > There are no technical reasons against using LGPLed RIOT to develop > proprietary applications. > > Using a "weird compiler" that cannot output the required object files > because it is closed source and proprietary is purely political. That > compiler could be changed trivially *if it would be open source* or the > vendor was inclined to do so. This doesn't count as technical reason. > > For me the sentence "RIOT allows LGPL + proprietary source code at the >> same level of comfort compared to Linux" sounds like a cheap marketing >> slogan making clear that the persons are not aware of the IoT diversity. >> > Saying otherwise makes clear that the persons are not aware of the > troubles embedded linux companies go through when developing proprietary > devices using (L)GPLed linux + libraries. > > What do you mean by "proprietary device"? From a professional point of view, I would not base strategic >> decisions on the discussed PR/idea. >> > What profession would that be? > > LGPL *is* putting restrictions on how and where the code is used. > That's the whole idea of a copyleft license. > > Kaspar > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi, On 02/20/15 12:41, Oleg Hahm wrote: Using a "weird compiler" that cannot output the required object files because it is closed source and proprietary is purely political. That compiler could be changed trivially *if it would be open source* or the vendor was inclined to do so. This doesn't count as technical reason. It's a political reason for the compiler vendor/provider - not for the person or company that wants to use RIOT and has to do it with that compiler for technical reasons. Opting for a device or environment that forces the use of such a compiler is a non-technical (political) decision by that person or company. Expecting the RIOT community to take that into account when deciding how to write code (see pointer discussion) or how to excercise our copyright is twisted. LGPL *is* putting restrictions on how and where the code is used. That's the whole idea of a copyleft license. Isn't there a "not" missing in your sentence? It's the other way around: "Copyleft guarantees that every user has freedom." (https://www.gnu.org/copyleft/) Which implicitly removes the freedom to take that freedom from others. That's the restriction. It's like, your liberty to swing your arm ends where my nose begins. Unrestricted freedom leads to a world of pain. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] tool chain recommendation
In case it helps, http://watr.li/samr21-dev-setup-ubuntu.html explains how I set up my dev environment for the SAMR :) Cheers, Lucas On 20/02/15 12:32, Ralph Droms (rdroms) wrote: On Feb 20, 2015, at 1:07 AM 2/20/15, Ludwig Ortmann wrote: Hi, I'm glad you found the wiki ;) Is there any way you would have found it even quicker, some location where we should put a link for example? I was aware of the wiki ... I just had to read a little more carefully to find the toolchain recommendation. - Ralph Cheers, Ludwig Am 20. Februar 2015 04:52:11 MEZ, schrieb "Ralph Droms (rdroms)" : I answered my own question by a little searching on the wiki - according to github.com/RIOT-OS/RIOT/wiki/Board%3A-Samr21-xpro I should use GNU Tools for ARM Embedded Processors toolchain. On Feb 19, 2015, at 9:52 PM 2/19/15, Ralph Droms (rdroms) wrote: What's the recommended toolchain for the SAMR21-XPRO board? - Ralph ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hey Kaspar! > Using a "weird compiler" that cannot output the required object files > because it is closed source and proprietary is purely political. That > compiler could be changed trivially *if it would be open source* or the > vendor was inclined to do so. This doesn't count as technical reason. It's a political reason for the compiler vendor/provider - not for the person or company that wants to use RIOT and has to do it with that compiler for technical reasons. > LGPL *is* putting restrictions on how and where the code is used. > That's the whole idea of a copyleft license. Isn't there a "not" missing in your sentence? It's the other way around: "Copyleft guarantees that every user has freedom." (https://www.gnu.org/copyleft/) Cheers, Oleg -- If no space is available nothing happens. RIOT/sys/net/include/pktbuf.h pgptpNg2_oJZ3.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] tool chain recommendation
> On Feb 20, 2015, at 1:07 AM 2/20/15, Ludwig Ortmann > wrote: > > Hi, > > I'm glad you found the wiki ;) > Is there any way you would have found it even quicker, some location where we > should put a link for example? I was aware of the wiki ... I just had to read a little more carefully to find the toolchain recommendation. - Ralph > Cheers, Ludwig > > Am 20. Februar 2015 04:52:11 MEZ, schrieb "Ralph Droms (rdroms)" > : >> I answered my own question by a little searching on the wiki - >> according to github.com/RIOT-OS/RIOT/wiki/Board%3A-Samr21-xpro I should >> use GNU Tools for ARM Embedded Processors toolchain. >> >>> On Feb 19, 2015, at 9:52 PM 2/19/15, Ralph Droms (rdroms) >> wrote: >>> >>> What's the recommended toolchain for the SAMR21-XPRO board? >>> >>> - Ralph >>> >>> ___ >>> devel mailing list >>> devel@riot-os.org >>> http://lists.riot-os.org/mailman/listinfo/devel >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hey Matthias, On 02/19/15 23:47, Matthias Waehlisch wrote: As you pointed out in your email, there are scenarios where the approach will not help due to technical reasons (and using a weird compiler might have technical reasons as well). You may consider these as irrelevant. But there is one aspect for sure in the IoT, the IoT is much more heterogenous compared to the current Internet. This is a crucial difference making the approach less suitable compared to developing for Linux, for example. Interesting how technical reasons are the main point you've read out my email. Let me correct myself. There are no technical reasons against using LGPLed RIOT to develop proprietary applications. Using a "weird compiler" that cannot output the required object files because it is closed source and proprietary is purely political. That compiler could be changed trivially *if it would be open source* or the vendor was inclined to do so. This doesn't count as technical reason. For me the sentence "RIOT allows LGPL + proprietary source code at the same level of comfort compared to Linux" sounds like a cheap marketing slogan making clear that the persons are not aware of the IoT diversity. Saying otherwise makes clear that the persons are not aware of the troubles embedded linux companies go through when developing proprietary devices using (L)GPLed linux + libraries. From a professional point of view, I would not base strategic decisions on the discussed PR/idea. What profession would that be? LGPL *is* putting restrictions on how and where the code is used. That's the whole idea of a copyleft license. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] About function pointers
Am Fri, 20 Feb 2015 08:01:58 +0100 schrieb Oleg Hahm : > Was this a vote for a function pointer based HAL or just a > Torvalds-like reflex? If the former is the case, then I'm apparently > the only one - counting the silent people on this topic as agreeing > or not caring - against this approach. In this case I would advice to > rethink and remodel the whole driver and HAL design. With the use of > function pointers it could be made extremely more (pseudo) > object-oriented what make many things much more convenient to > implement. Hi Oleg, I vote for "function pointer based HAL" and I think more of them will make RIOT much better :-). -- Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF radio driver
Hi Joakim, On 20 Feb 2015, at 9:31 CET(+0100), Joakim Gebart wrote: > Thank you for the prompt response. I will start reading the existing > drivers but I think I will wait at least until there is a PR for the rf231 > before I begin my implementation work. As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we want to use it on EmbeddedWorld on Tuesday you can expect a PR for this soonish. :-) Best, Thomas ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF radio driver
Thank you for the prompt response. I will start reading the existing drivers but I think I will wait at least until there is a PR for the rf231 before I begin my implementation work. Best regards, Joakim PS: Sorry, you are "Joakim" not "Joachim" :-) Am 20.02.2015 um 08:51 schrieb Peter Kietzmann: > Hi Joachim, > > I think it will be the at86rf231-driver (in near future). @thomaseichinger > is currently working on the refactoring according to the network > restructuring. There is still no PR but as far as I know the progress is > well. I think it's wise to wait at least until this driver is merged, as it > acts as a proof-of-concept for network devices. I assume there won't be > many changes to the netdev API. So if you cannot wait with this for time > reasons, the potential adoptions might be small (I hope :-) ). > > Best, > Peter > > > Am 20.02.2015 um 07:25 schrieb Joakim Gebart: > >> Dear RIOT developers, >> - Which radio driver is the most up to date with regards to the >> network stack restructuring work being done in #2278? >> - How stable is the radio device API currently? Are there any more >> API changes coming? >> - Would it be wise to wait until the restructuring todo list is >> mostly checked off until starting work on implementing a new radio >> device driver? >> - Which driver would be best to use as an example of a fully >> compliant radio driver? >> >> I am looking at implementing a driver for a new radio chip, but I do >> not want to have to redo the work again in a couple of weeks because >> of the network refactoring... >> >> https://github.com/RIOT-OS/RIOT/issues/2278 >> >> Best regards, >> Joakim Gebart >> Managing Director >> Eistec AB >> >> Aurorum 1C >> 977 75 Luleå >> Tel: +46(0)730-65 13 83 >> joakim.geb...@eistec.se >> www.eistec.se >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> > > -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
