This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Phoenix-RTOS: Add caddr_t definition to <sys/types.h>.
- From: Jakub Sejdak <jakub dot sejdak at phoesys dot com>
- To: newlib at sourceware dot org
- Date: Wed, 29 Jun 2016 16:57:13 +0200
- Subject: Re: [PATCH] Phoenix-RTOS: Add caddr_t definition to <sys/types.h>.
- Authentication-results: sourceware.org; auth=none
- References: <1467103669-8216-1-git-send-email-jakub dot sejdak at phoesys dot com> <20160628105224 dot GA23625 at calimero dot vinschen dot de> <CAFvk=0s8C9_=+RWfZ1jeYNheidb47gFhQn2jQbrpuAFmzNwHog at mail dot gmail dot com> <20160628130148 dot GB4685 at vapier dot lan> <CAFvk=0tncqOq4EaadYokr4198ZaADjCqD_hsMTWW3RnwTFmD8g at mail dot gmail dot com> <20160629135343 dot GT4685 at vapier dot lan>
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 <vapier@gentoo.org>:
> 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 (www.phoesys.com)
+48 608 050 163