This is the mail archive of the 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]

Re: [PATCH] Phoenix-RTOS: Add caddr_t definition to <sys/types.h>.

1) I fully understand all of you. And I don't want to change any code
organization in newlib in general, just in our private directory.

2) If you are so against copying headers to private OS directory
(where each OS can make any changes and it has no impact on all
other), then why is it even allowed?
As an example, look at Linux port. It has exactly the same situation.
Even types.h is there with some changes.

If they are allowed to do so, why we can't?

2016-06-29 15:53 GMT+02:00 Mike Frysinger <>:
> 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

Jakub Sejdak
Software Engineer
Phoenix Systems (
+48 608 050 163

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]