Thanks for the comments, I'll fix assert and create a pull request so additional discussions can be in the github project.
On Tue, Jun 23, 2015, 5:08 AM Matthew Fernandez < matthew.fernan...@nicta.com.au> wrote: > Hi Wink, > > The guards you've used look sufficient (though it's mildly concerning that > any poor user who received your libsel4's > assert.h before libc's has their asserts unconditionally become no-ops). > We also previously explored the option of using > different typedef names, but felt it led to unnecessary confusion when > reading the stubs. I'm not debating whether these > things can be checked for at compile time, but IMHO the necessary checks > in a large build system are more complex than > one might initially imagine. > > I don't have any objection to minimal systems and probably no one who > works on microkernels does. Personally I think > implementing a C application without including libc is signing yourself up > to re-implement libc, but if you're OK with > that than fair enough. I'm not opposed to the idea behind this proposal, > of removing the libsel4->libc dependency, but > since I am unlikely to be the one maintaining it, I'll leave it to others > to make a call on whether to go in this direction. > > Cheers, > Matt > > On 23/06/15 21:03, Wink Saville wrote: > > Matt, > > > > I've guarded the definitions with conditionals to try to avoid that, but > maybe a better option might be to use different > > names completely. Also, we could test for compatibility at compile time > and generate errors. > > > > My rational for wanting this is that libc doesn't seem to be providing > that much value as very few of its vsyscalls are > > implemented anyway. Thus its utility is actually small, IMHO. Also, I > happen to be interested in minimal systems so > > unused and extraneous code is an anathema. Here, in libsel4, by adding > these few LOC's we are removing "thousands" of > > LOC brought in by the need of a libc. > > > > Anyway, I'd certainly like to keep the discussion going to revisit the > the earlier decision, I just feel strongly the > > less code the better. > > > > > > On Tue, Jun 23, 2015, 12:02 AM Matthew Fernandez < > matthew.fernan...@nicta.com.au > > <mailto:matthew.fernan...@nicta.com.au>> wrote: > > > > Hi Wink, > > > > As you've observed in that commit, removing the libc dependency > leads you to re-implement pieces of it inline. We used > > to do something similar to this, but replaced this with an explicit > dependency on libc to avoid complications with > > multiple definitions of typedefs and such. In the case of programmer > error, these typedefs may not match and if the > > conflicting typedefs are never seen within the same translation unit > your compiler will not notice either. The end > > result was subtle bugs arising from ABI incompatibility. > > > > When we made the change, out rationale was that anyone using the > syscall stubs would have libc available anyway. This > > certainly introduces a circular dependency, but it's not easy to > remove without repeating parts of one library in the > > other or playing tricks with externs and weak symbols. In my > experience, all of this is more fragile and less preferable > > than living with the circular dependency. However, my opinion may > not be universally shared as we haven't had a > > discussion about this for some time. > > > > Cheers, > > Matt > > > > On 23/06/15 11:16, Wink Saville wrote: > > > I noticed that seL4/libsel4 was dependent upon libc and so I > created a patch > > > ( > https://github.com/winksaville/seL4/commit/fc91a1f68c054fdb41aaa42a7b56a80f481b68b2) > which removes the > > dependency. If > > > there is interest I can submit a pull request, and of course will > make any changes deemed necessary to make it > > suitable > > > for acceptance. > > > > > > Please advise, > > > > > > Wink > > > > > > > > > _______________________________________________ > > > Devel mailing list > > > Devel@sel4.systems > > > https://sel4.systems/lists/listinfo/devel > > > > > > > ________________________________ > > > > The information in this e-mail may be confidential and subject to > legal professional privilege and/or copyright. > > National ICT Australia Limited accepts no liability for any damage > caused by this email or its attachments. > > >
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
