Serial port, unix calls, some thoughts

David T. Lewis lewis at mail.msen.com
Tue May 27 10:05:36 UTC 2003


On Mon, May 26, 2003 at 10:34:32PM -0700, John M McIntosh wrote:
> Dan asked me to add a better degree of serial support to the mac os-x  
> VM, and it seems one just uses the Unix calls for this, versus apple  
> specific stuff.
> 
> Now in looking at this I was thinking here I've all these calls like
> cfgetispeed, cfgetospeed, cfmakeraw, cfsetispeed, cfsetospeed, open,  
> close, read, write, ioctl
> tcdrain, tcFlow,t cFlush, tcgetattr, tcsetattr, tcsendbreak
> 
> So I was thinking, why not make the actual primitives really sparse to  
> avoid C code that would require
> support and VM changes, and then produce implementation specific  
> subclasses like so?
> 
> SerialPortExtended
> SerialPortExtendedUnix
> SerialPortExtendedUnixOSX

That's pretty much the approach I took with OSProcess. Class OSProcessAccessor
is responsible for interacting with the OS calls, with platform specific
subclasses for Unix, Win32, etc. I keep the OSPP plugin as thin as possible,
and there has been no need for externally maintained C support code.

The termios(3) stuff is big enough and messy enough to merit its own
plugin and support classes (versus putting even more crud into OSPP). But
I think the approach you are describing is a good way to do it. Note that
Squeak has rather inconsistent ways of getting at the FILE* for files
and sockets, and getting at the underlying Unix file descriptor is yet
another level of indirection. Also Windows is using Win32 HANDLEs for
the low level IO.  You can borrow some code from OSPP and IOHandle to
get at this.

> {I'll note that I do capture errno in the C code, versus looking for it  
> in the smalltalk, however my concern is that
> going to get errno after the fact might return zero because someother  
> unix call(s) could be made before our
> process thread could retrieve it.}

You can easily pass errno back to Squeak. Hmm... I put that in OSPP but
haven't released it yet, badly need to get caught up here.

> So thoughts?

IO handling in Squeak is kind of a mess. See IOHandle on SM or the
swiki for some further thoughts on this (not kept up to date, but you'll
get the idea).

Dave



More information about the Squeak-dev mailing list