openssh port to VxWorks

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
What are the major issues in porting openssh (portable) to VxWorks? I know
of a few companies who SELL this port. Does this really mean that the
complexity is overwhelming? Can someone give a feel for how much effort may
be needed to port openssh to VxWorks...


Re: openssh port to VxWorks

Manish Mukherjee wrote:

Quoted text here. Click to load it

Well VXWorks is a realtime UNIX correct? I am not sure how much work that
would be but, you could check it out relatively easily.

If you go to their should be some docs about compiling the
program. In these docs their usually list the required software (ie, etc, etc) From there you can check to see what you can get on
VXWorks. I imagine that it can be done. Might take a little work...but
definitely do'able...



"Microsoft isn't evil, they just make really crappy operating systems." -
Linus Torvald

Re: openssh port to VxWorks

Quoted text here. Click to load it

No, VxWorks is definitely not "a realtime UNIX". "A realtime OS with
some Unix-ish (or POSIX-ish) properties" is more like it. It was quite a
while since I did any serious work on VxWorks, and many of its
"differences from Unix" can be worked around or avoided in various ways,
but for a standard/default VxWorks system, I believe these are still
some of the more important issues that will face the porter of a typical
Unix program:

- A single address space for the whole system (i.e. VxWorks "tasks" are
  threads rather than processes in Unix terminology - the entire system
  would be a "process").

- A single symbol table for the whole system.

- While loading code obeys the "standard" semantics wrt to initialized
  data segments and BSS, you don't normally load code on each invocation
  - rather load it once (unless it's burned into PROM:-) and just call a
  function (which had better not be called "main") for multiple

- No "automatic cleanup" on exit of a "task" - i.e. allocated memory
  remains allocated, opened files/sockets remain open, etc.

- Low-level "HW" stuff is entirely different, even as seen from a
  "user-level" program (of course there is no "user-level", but...) -
  e.g. such mundane things as tty-related ioctl()s are very different.

- File system semantics are entirely different - or rather, VxWorks
  doesn't have a file system with Unix/POSIX semantics (NFS is probably
  the closest).

Quoted text here. Click to load it

Uh, you're mostly on a different wavelength here...

Quoted text here. Click to load it

Definitely doable (anything that isn't?:-), but definitely not a
"little" work.

--Per Hedeland

Site Timeline