Re: [riot-devel] About function pointers
Am Fri, 20 Feb 2015 08:01:58 +0100 schrieb Oleg Hahm oliver.h...@inria.fr: 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] 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 ludwig.ortm...@fu-berlin.de 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) rdr...@cisco.com: 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) rdr...@cisco.com 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] 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 kas...@schleiser.de 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 - 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 m.waehli...@fu-berlin.de 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 - 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
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] 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 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
