Initial commit for mbed-lib

[bogdanm]

mbed-lib is a system library for mbed, its job is to provide implementations of various data structures and algorithms used in mbed. It is similar in scope to https://github.com/ARMmbed/foundation (and will likely get some components from there), but geared more towards mbed. It has a few advantages:

• some libraries can depend on mbed-lib instead of mbed-core, which is a much more "lightweight" dependency
• it's not supposed to depend on mbed-core (see also the above point), which means that with the proper support code it should be usable on non-mbed platforms, for example POSIX based test environments

Initial components:

• critical section lock (implementation taken from https://github.com/ARMmbed/minar/blob/master/source/minar.cpp)
• pool allocator (implementation adapted from https://github.com/ARMmbed/system-pool)

Planned components:

• extendable pool allocator (soon to come)
• FunctionPointerX and Event (moved from mbed-core)
• generic data structures
• ...

[bogdanm]

@autopulated @0xc0170 please CR.

[autopulated]

would util be a better name/namespace than lib? mbed-lib might be confused for "the mbed library".

[bogdanm]

OK, what do you suggest? syslib ? systemlib ? corelib ? (I vote for syslib)

[hugovincent]

Two thoughts from me: 1) I don't think prefixing stuff with mbed- adds much. If we take that away, the name lib is probably a bit too general ;-) 2) If you can't find a good name for a thing, it suggests the concept for what the thing is/will be, isn't quite fully baked yet. This sounds like it will have initially two things in it, with possibly a few more added later. Both of the current ones (poolalloc, critsect) are completely decoupled from one another by the looks. Why not have them in their own modules?

[autopulated]

I'd suggest mbed-util / mbed::util::. This might be a good module to apply the release name-space versioning guidelines too also.

[bogdanm]

@hugovincent :

1) That may be true, but we're using the mbed- for most of our repositories. I agree we should have a clear convention about this, otherwise things become confusing. 2) This thing is a library of utilities, so in this respect, James's suggestion makes more sense. Personally, I am not at all a big fan of having a lot of small repos doing exactly one thing right. I know it sounds very good on paper, but experience already suggests that tracking and updating the dependencies between all these small repos becomes a huge PITA. If you were to design a libc, would you have your libc repository depend on a number of sub-repositories, one of which is the allocator, the other one(s) being printf(), I/O operations and so on? (hint: I wouldn't). This is similar in concept.

[bogdanm]

I'm going to delete this and re-create it under mbed-util, as suggested by James.