libc support is important and desirable in many contexts, but simplicity is important too. if libsel4 can be made to not depend upon libc I believe that is an advantage.
Anyway, I've created a pull request (https://github.com/seL4/seL4/pull/14) which allows seL4test on the qemu x86 pc99 simulation (make simulate-ia32) to continue to pass. Please review and add comments there if you're interested. On Tue, Jun 23, 2015 at 6:27 PM Tom Mitchell <[email protected]> wrote: > One important aspect of the C library is that it covers and bridges two > universes. > One is the system call interface to the kernel. A micro kernel needs > more bridging. > Second are features and functions for common programming > activities and manipulation of common data structures. > > http://www.gnu.org/software/libc/manual/pdf/libc.pdf > > The common things like math libraries and more string handling... pattern > matching. > Things like users and groups are possibly a do not care on a sensor but > math > and binary to character conversions have value. > Users, groups and permissions are the framework for security.... > Filesystem code in the kernel enforcers access as well as maintaining > data to blocks on disk mappings but could be done in user space. > > One working model to inspect this is the Cygwin project that builds > on a Windows foundation and gives the programer a Unix like API. > https://www.cygwin.com/ > Look to see how differences in the Windows model and Unix (posix) model > are managed and errors handled. > > A key part is error handling. > > > > On Tue, Jun 23, 2015 at 8:18 AM, Wink Saville <[email protected]> wrote: > >> 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 < >> [email protected]> 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 < >>> [email protected] >>> > <mailto:[email protected]>> 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 >>> > > [email protected] >>> > > 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 >> [email protected] >> https://sel4.systems/lists/listinfo/devel >> >> > > > -- > T o m M i t c h e l l > _______________________________________________ > Devel mailing list > [email protected] > https://sel4.systems/lists/listinfo/devel >
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
