On Jun 26, 2019, at 9:02 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On 6/24/19 6:23 PM, Siva Chandra via llvm-dev wrote: >> Within Google, we have a growing range of needs that existing libc >> implementations don't quite address. >> To be very clear: we don't expect our needs to exactly match everyone >> else's -- part of our impetus is to simplify things wherever we can, and >> that may not quite match what others want in a libc. >> There are also few areas which we do not intend to invest in at this point: >> Implement dynamic loading and linking support. >> Support for more architectures (we'll start with just x86-64 for >> simplicity). >> So, what do you think about incorporating this new libc under the LLVM >> project? > The null hypothesis is to not add a project to LLVM. In order to add a > project, it should be justified. What are the justifications here? I've > quoted the snippets above where it is made clear that Google's needs do > *not* line up with the needs of the community. But the proposal failed > to mention what the actual needs of Google are. > > So what are they?I really have nothing to do with this project, and no insight on the thoughts behind it, but I think you and several other people on this thread have missed a significant issue: the thread is conflating whether it is a good idea to "create yet another libc" with whether it is a good idea to "contribute that code to LLVM". I don’t think arguing whether or not someone should build a project is on-topic for this list. Given that they appear motivated to build it, the question is whether this fits into the LLVM umbrella. With my LLVM hat on (I also work for Google, but am unaffiliated and uninvolved with this proposal), it appears clearly beneficial for LLVM to have a libc if it were done well. That said, clang shouldn’t/couldn't *require* one specific libc, just like we don’t require libc++ as the standard library. We want LLVM components to be mixable and matchable. I appreciate the comments on this thread that are throwing in ideas for how to make the project better, how to ensure it grows to being a successful and widely useful component of LLVM, etc. I for one think that this could be very useful for people building custom micro targets, and being able to build custom configs of a libc without (e.g.) stdio or libm would be a nice way to shed weight. -Chris
On 6/26/19 12:42 PM, Chris Lattner wrote:> On Jun 26, 2019, at 9:02 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 6/24/19 6:23 PM, Siva Chandra via llvm-dev wrote: >>> Within Google, we have a growing range of needs that existing libc >>> implementations don't quite address. >>> To be very clear: we don't expect our needs to exactly match everyone >>> else's -- part of our impetus is to simplify things wherever we can, and >>> that may not quite match what others want in a libc. >>> There are also few areas which we do not intend to invest in at this point: >>> Implement dynamic loading and linking support. >>> Support for more architectures (we'll start with just x86-64 for >>> simplicity). >>> So, what do you think about incorporating this new libc under the LLVM >>> project? >> The null hypothesis is to not add a project to LLVM. In order to add a >> project, it should be justified. What are the justifications here? I've >> quoted the snippets above where it is made clear that Google's needs do >> *not* line up with the needs of the community. But the proposal failed >> to mention what the actual needs of Google are. >> >> So what are they? > > I really have nothing to do with this project, and no insight on the thoughts behind it, but I think you and several other people on this thread have missed a significant issue: the thread is conflating whether it is a good idea to "create yet another libc" with whether it is a good idea to "contribute that code to LLVM". I don’t think arguing whether or not someone should build a project is on-topic for this list. Given that they appear motivated to build it, the question is whether this fits into the LLVM umbrella.I don't understand your reasoning here. If there's reason to believe it should not be built at all, wouldn't that also imply that it shouldn't be taken under LLVM's umbrella? The LLVM community (including myself) will be responsible for maintaining this software and to do that we must figure out the specifications, trade-offs, and use cases. How should we determine the requirements of something that has no reason to exist? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/ee250ef4/attachment-0001.sig>
On Jun 26, 2019, at 10:16 AM, Andrew Kelley <andrew at ziglang.org> wrote:> >> >> I really have nothing to do with this project, and no insight on the thoughts behind it, but I think you and several other people on this thread have missed a significant issue: the thread is conflating whether it is a good idea to "create yet another libc" with whether it is a good idea to "contribute that code to LLVM". I don’t think arguing whether or not someone should build a project is on-topic for this list. Given that they appear motivated to build it, the question is whether this fits into the LLVM umbrella. > > I don't understand your reasoning here. If there's reason to believe it > should not be built at all, wouldn't that also imply that it shouldn't > be taken under LLVM's umbrella? The LLVM community (including myself) > will be responsible for maintaining this software and to do that we must > figure out the specifications, trade-offs, and use cases. How should we > determine the requirements of something that has no reason to exist?I don’t see the connection. The LLVM project exists to foster compiler and toolchain related technologies that align with its developer policy (including license, library based design etc). This proposal aligns directly with that mission. I don’t see why something being part of LLVM means that you necessarily need to support it or “maintain" it. Do you maintain vmkit, which is also part of LLVM? OTOH, I agree with you that something becoming an LLVM subproject means that it is likely to gain traction over time and become a default answer with new targets that come up. If there are other existing libc implementations that want to align with the mission (incl, design goals, coding standard, licensing, etc), then I encourage them to step up and provide other compelling alternatives to consider. If no compelling alternative to consider steps forward, then the primary question (from the LLVM perspective) is whether a new project aligns with the mission or not. We have no track record of rejecting a proposal based on the theory that some better alternative *could theoretically* exist. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/d53851c9/attachment.html>