This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 28 Jun 2016 16:35, Jakub Sejdak wrote: > > libc/include/sys/types.h provides all the types already. why do you > > need to duplicate it ? there's a ton of such examples in the pheonix > > codebase. > > Because we needed to move few type definitions to kernel, thus now > types.h is not identical as one in common newlib space. The same rule > applies to other headers that are copied to sys/phoenix/sys private > directory. the common newlib sys/types.h has mechanisms for overriding type sizes via sys/_types.h. you should be using that mechanism, not duplicating sys/types.h entirely. if something in sys/types.h can't be controlled, then you propose a patch so that sys/_types.h can control it. > > i don't see how that's relevant to an open source project > > I said this, because someone before proposed me to have all > definitions in newlib, not in kernel, and include libc headers into > kernel adding #ifdef _KERNEL or similar where appropriate. This is not > an option, because of our policy. to reiterate: private company policy on code organization does not trump the open source project's policy on code organization. if you have some manager somewhere saying you need to do X but it's in direct opposition to newlib saying do Y, then you're free to fork and do X internally, but the public code is going to do Y. open source projects are not beholden to companies. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |