Hi again,
In the first email of the thread I tried giving a fair exposition of the question, now I'm going to give my personal opinion.
Similarly to what I suggested for timing.c, I'm inclined to remove net.c as such, move most of its content (net_bind(), net_accept(), etc.) out of the library (most probably into a new file in programs/ssl, shared by SSL examples), and keep in the library only the 3 functions that can be used as SSL callbacks (and a supporting context type), but in a new module named for example ssl_io_sockets.c.
This would also be similar to the other SSL modules that provide a reference/example implementation of some SSL callback but can easily be disabled (or jsut disregarded) in favour of a custom implementation for custom needs or unsupported platforms. Just like the current net_sockets.c, this new reduced module would probably only be supported on platforms with sockets, which is Posix platforms and Windows.
Advantages include:
- Reduce the amount of code and API surface in the library. Things like binding and accepting are hardly related to (D)TLS so there is little justification for having them in the library. Also, things in the library are bound by API stability rules which are sometimes a constraint.
- It would clarify that we're not providing a general-purpose socket abstraction, as general socket management would be out of the library, and only the bits for plugging a socket into our SSL layer would be in the library.
- (By the way currently net_sockets.h includes ssl.h, so it's already quite specific to our SSL module rather than generic, but moving the remaining bits of it into the SSL namespace would make that clearer.)
- User would still have the convenience (on supported platforms) of ready-for-use callbacks. If you have an application already working with sockets without TLS, then we provide all the bits needed to turn that into an application using TLS on top of those sockets.
I think that would be a good compromise between convenience for users, and reduced surface for the library.
Regards, Manuel.
mbed-tls@lists.trustedfirmware.org