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
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.fernandez@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
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
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
LOC brought in by the need of a libc.
Anyway, I'd certainly like to keep the discussion going to revisit the
less code the better.
On Tue, Jun 23, 2015, 12:02 AM Matthew Fernandez < matthew.fernandez@nicta.com.au mailto:matthew.fernandez@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
On 23/06/15 21:03, Wink Saville wrote: that much value as very few of its vsyscalls are these few LOC's we are removing "thousands" of the earlier decision, I just feel strongly the 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/fc91a1f68c054fdb41aaa42a7b56a80f4...) 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
-- T o m M i t c h e l l