Matt Johnston wrote:
> It mightn't be necessary to pass pointers around everywhere if
> ses/svr_ses/cli_ses could be thread-local pointer variables - how widely
> supported is thread-local storage?
If you can get a "current thread id" or set one "thread-local value", you can
make thread-local
Hi Sebastian,
I'd be interesting in merging changes upstream, I think it would be of interest
to a few people. It would need to be under a similar license to the current
code.
Currently the session state is kept in ses, svr_ses, and cli_ses global
variables (all structs defined in session.h).
Hello,
thanks for the hints.
So, running dropbear in a single-address space and no process
environment seems to be doable. However, it requires probably some
possible large code modifications, e.g.
* encapsulate the global state in a context structure and pass a pointer
to this structure
Hi Sebastian,
Dropbear probably won't fit without some modifications, though likely wouldn't
be that hard to get working with only a single connection at a time. There's a
global state variable, and may be a few other assumptions that the vforked
child is going to exec() (like uClinux).
Recent
Hello,
I would like to use SSH to do some remote administration for an
application running with the RTEMS real-time operating system. In this
environment we have no virtual memory and user and kernel space
separation. So this is like an application running in kernel mode only.
Is it in
