Re: [riot-devel] enums vs. macros
A silly question/suggestion:
Wouldn't it make sense to use sized integer types in the struct, but a separate
enum to define the values? IIRC, enum's in C are simply named integer
constants. C is also very permitting in storing values into smaller integer
types. For C++, of course, the situation may not be that easy.
typedef struct {
uint16_t flags;
} foo_t;
typedef enum {
FOO_FLAG_ONE = 0x01,
FOO_FLAG_TWO = 0x02,
FOO_FLAG_THREE = 0x04,
} foo_flags_t;
--Pekka
On 2015–05–13, at 9:12 , Oleg Hahm oliver.h...@inria.fr wrote:
Dear replying IoTlers,
some time ago I had a discussion with Martine on GitHub about the usage of
enums for flags [1]. Martine convinced me that seems to be wise to prefer
macros over enums here, to avoid alignment issues. However, it feels somehow
wrong not to use enums for this purpose (it's easier for the developer *and*
the compiler if a valid data type is chosen). Does anyone know a trick around
the issues that Martine mentioned:
Because flags have a width in memory that is in most cases smaller than
sizeof(enum) (most bit fields I know of are 16 bits max, on most of our
newer platforms, sizeof(enum) is however 32 bits). This results in every
assignment needed to be cast to either uint8_t or uint16_t. With macros you
don't need to cast since they are typeless.
Making the enum packed makes it's width unpredictable in terms of alignment
issues, when used in struct (which is not the case here, I know).
Cheers,
Oleg
[1] https://github.com/RIOT-OS/RIOT/pull/2614#discussion_r28941692
--
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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Dear Emmanuel, all; Personally, I laud this decision. It appears reasonable and based on a well founded analysis. Congratulations, to the whole community! --Pekka On 2015–03–22, at 15:02 , Emmanuel Baccelli emmanuel.bacce...@inria.fr wrote: Dear all, thanks for the input from everyone on this topic. It is a tough case to decide, based on our long and detailed exchanges on this subject. But it is probably time to conclude. At INRIA, we came up with the following observations: - there is no enthusiastic majority for a license change to BSD/MIT, - as solutions competing with RIOT are quasi-exclusively BSD/MIT, (L)GPL is a way to stand out positively. Concerning this last point, we observed that staying on the (L)GPL side strengthens our position comparing ourselves to Linux -- which has been one of our key non-technical arguments so far. Furthermore, studies such as [1] show that small companies and start-ups are going to determine IoT. More than bigger companies, such small structures need to spread development and maintenance costs for the kernel and all the software that is not their core business. Our analysis is that this is more compatible with (L)GPL than with BSD/MIT. We are of the opinion that, compared to BSD/MIT, (L)GPL will improve final user experience, security and privacy, by hindering device lock-down, favoring up-to-date, and field-updgradable code. We think this a more solid base to provide a consistent, compatible, secure-by-default standard system which developers can build upon to create trustworthy IoT applications. Last but not least, we think that (L)GPL is a better base than BSD/MIT to keep the community united in the mid and long run. For these reasons, even though we still believe a switch to BSD/MIT would facilitate RIOT's penetration rate initially, we want to continue releasing under LGPLv2.1. I also want to point out that even though this is basically status quo, we think this discussion was far from useless, because it helped clarify where we stand, and for what. From our point of view, the next steps are now to set up a non-profit legal entity for RIOT, and to put CLAs in place, allowing non-exclusive rights for the code to this legal structure. Best, Emmanuel [1] http://www.gartner.com/newsroom/id/2869521 http://www.gartner.com/newsroom/id/2869521___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] About function pointers
Oleg, all, Just as one data point, modern compilers are able to optimise out function pointers if they are constant. That is, if the struct containing the function pointer is a const struct, in a typical case static const, then e.g. LLVM is able to optimise the function pointer call into the resolved function call, even during linking time. I'm not sure if GCC can do that in link time, but if the struct is defined as a static struct in a header file, it is able to optimise out the struct, including any function pointers in it. Of course, some care is needed to make sure that the compiler does the right thing. It is relatively easy to break the pattern. --Pekka On 2015–02–18, at 12:38 , Oleg Hahm oliver.h...@inria.fr wrote: Dear remodeling IoTlers! Ludwig just made me aware that Joakim's PR for NVRAM [1] introduces function pointers as part of the device driver struct. This made me remember that there were already similar function pointers introduced as part of netdev. As I was always opposed to use function pointers in that way, I could not recall what was the reason to use them for netdev. I don't like this pseudo object oriented C style (dev-write() and the like) because we made bad experiences with it at my former company. While writing the whole HAL for our firmware there using function pointers this way, made programming pretty convenient, it turned out to become problematic speed-wise and was a nightmare to debug. Hence, I would like to trigger a fundamental discussion on this topic. Does anyone has a particular opinion on the topic why function pointer based device drivers should be a good or a bad idea? And can anyone explain to me the need of function pointers for netdev? Cheers, Oleg [1] https://github.com/RIOT-OS/RIOT/pull/2353 -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ linux-2.4.0-test2/drivers/parport/parport_pc.c ___ 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
