I am going to use the PF_UNIX internal socket implementation to talk to
the resource manager. It should be fairly simple and will also let me
easily implement external sockets when I create inter resource manager
communications between multiple machines. As Spafford is saying we should
make it
On Tue, Sep 29, 1998 at 09:11:44AM -0500, David Corcoran wrote:
> Please answer if you know the following question I'm going to ask. I'm looking
I don't know THE answer. This are only my opinions.
> now for the best way to make our current resource manager available to
> applications. What is t
Please answer if you know the following question I'm going to ask. I'm looking
now for the best way to make our current resource manager available to
applications. What is the best way ? If the Resource Manager was a shared
object with some variables declared statically would multiple apps be a
Hey Folx,
First I wnat to say that everybody in this project is doing a great job.
But we shouldn't loose the the focus.
I think there shouldn't be a discussion about OS-independent driver. The driver has to
run under Linux. Everything else is 'nice to have'.
That's it, the driver should work,
Hi
> I'm following this structure in my Towitoko CT-API driver:
>
> - serial.c, .h: Functions for reading and writing serial port. This code
> is plataform dependent but reader independent. I'm planing add support for
> Win32 (with a new define CPU_WIN32_OS) so the CT-API would work on Linux,
> M
On Tue, 29 Sep 1998, Paolo Bizzarri wrote:
> 3) Last, why not defining and using a single standard set of functions
> for serial I/O ? I have seen that mct and reflex both use an
> incompatible library.
>
I'm following this structure in my Towitoko CT-API driver:
- serial.c, .h: Functions fo