[ On Tuesday, May 22, 2001 at 08:58:58 (-0700), Peter William Lount wrote: ]
> Subject: Re: SerialPort problem in UNIX Squeak 3.0 vm on FreeBSD
>
> I would like to point out that Unix style operating systems have multiple
> device names for the same device depending on how you wish to use the
> device. For example, "/dev/ttyd0" is the same device as "/dev/cuaa0" except
> that "/dev/ttyd0" expects extra serial port pins to be connected for
> hardware flow control while "/dev/cuaa0" does not expect that. So in some
> situations you might have a need to "intermix" these devices thus the need
> to be able to control individual devices "paths".

Very good point!  Of course the names are different on Solaris and
NetBSD and so on too....

> If you wanted auto configure to actually set the devices individually it
> would have to scan the hardware that it's being installed upon and find all
> the serial devices. How complex would that be?

That would definitely be the wrong approach.  The VM binary should not
have any specifics about the hardware configuration of any given host
compiled into it!  The binary should be kept portable, which means that
all configuration of pathnames and the like must be done at runtime.

> Using Smalltalk to override the base device and any individual devices:
> 
> SerialPort setBaseDevicePath: "/dev/cuaa0"; reinitialize.
> SerialPort
>     setDeviceNumber: 0 path: "/dev/cuaa0";
>     setDeviceNumber: 1 path: "/dev/ttyd1";
>     reinitialize.

That kind of thing could work for initial configuration too (i.e. *not*
to override the defaults, but rather to *provide* the defaults!), though
as I suggested in my other note the necessary use of an index number
seems rather inelegant to me.

> What is needed at the primitive level is an array of path names for each
> device (with some limit like 16, 32 or 64 of them) that gets initialized to
> some default path each with it's unique number and path string. An
> additional primitive for setting a new base and for setting individual
> device paths would also be needed. Once you've set these paths the serial
> port object may need to be reinitilized especially the device ports that
> have been changed and that are currently open. Closed device paths probably
> don't need any reinitializing if their path didn't change.

No, don't go down that road either!  Too much hard-coded, including
limits.  The binary VM should be completely neutral w.r.t. system
specific pathnames, numbers of devices, etc.

Indeed I should be able to take any Linux or FreeBSD binary VM and run
it under emulation on my NetBSD system!  Indeed that works now in the
most basic sense (except of course for serial ports and the need for
having local copies of all shared libraries, etc.).

> These changes should be simple to implement at the C level. Ok, maybe the
> xml configuration file is done at the Smalltalk level and given the right
> primitives to make these changes then it can be done easily when the image
> starts up.

Why use XML for config files?  Why not just use ordinary smalltalk
expressions?  Certainly the "unix way" is to write configuration files
in the syntax of the interpreter!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>