Hi,
I have another feature request, which came up while working with solo5.
In my runtime I have multiple places where some kind of debug data is
dumped, e.g., there is the possibility to write heap dumps and an event
log. Theses things are used only for debugging and profiling. Probably
if all the higher level infrastructure is in place, the network
interface could be used to send a debug stream. But then the lowlevel
runtime would have to call into the highlevel network driver.
Alternatively the block devices containing a filesystem could used for
dumping, but then the data would be written which is not desired.
My wish would be to have something like this instead of the console.
typedef struct solo5_stream_* solo5_stream;
#define SOLO5_STREAM_INVALID ((solo5_stream)0)
#define SOLO5_STREAM_OUT ((solo5_stream)1) /* always available */
#define SOLO5_STREAM_ERR ((solo5_stream)2) /* always available */
solo5_stream solo5_stream_open(const char* name);
void solo5_stream_write(solo5_stream stream, const char* buf, size_t
size);
void solo5_stream_close(solo5_stream stream);
Since such a change would also increase the attach surface, these calls
should be locked and should be only available during a debugging mode.
Ideally the hypervisor should be compiled without these calls in release
mode, where solo5_stream_open will always return SOLO5_STREAM_INVALID
and solo5_stream_close will be a nop.
Maybe you have other suggestions on how to solve these issues. Did
something like that come up before?
Another question concerns the solo5_result_t type. Is it realistic to
get rid of this errors altogether and ensure that the block/net calls
never fail? For example instead of returing EINVAL, the application
could just be terminated since something is very wrong. The same might
also hold for the EUNSPEC error. Are these errors in place to allow
kernels to do a proper shutdown? Since this is the only reasonable thing
to do.
The only error which seems to be needed from my superficial point of
view is EAGAIN for solo5_net_read, but the call could also just return 0
in that case. Maybe the solo5_net_write call could also return EAGAIN,
if some network buffer is full?
Daniel
