Re: [riot-devel] enums vs. macros

2015-05-13 Thread Pekka Nikander
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;


 On 2015–05–13, at 9:12 , Oleg Hahm 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).
 panic (No CPUs found.  System halted.\n);
 devel mailing list

devel mailing list

Re: [riot-devel] Switch to BSD?

2015-03-22 Thread Pekka Nikander
Dear Emmanuel, all;

Personally, I laud this decision.  It appears reasonable and based on a well 
founded analysis.

Congratulations, to the whole community!


 On 2015–03–22, at 15:02 , Emmanuel Baccelli 
 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 
 - 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.
 devel mailing list

Description: S/MIME cryptographic signature
devel mailing list

Re: [riot-devel] About function pointers

2015-02-18 Thread Pekka Nikander
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.


 On 2015–02–18, at 12:38 , Oleg Hahm 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?
 if (user_specified)
/* Didn't work, but the user is convinced this is the
 * place. */
 devel mailing list

devel mailing list