I am in the process of writing a resource manager for a goofy RS-232 serial
communication application that requires (occasionally) that data be
transmitted at a particular baud rate and the reply data be received at a
different baud rate. I would like to implement the “standard” POSIX
interface. I have the char DDK and the io-char source from the QNX CVS
repository. The only solution I have come up with so far is to add a new
DCMD to allow a client process to specify a termios struct needed to receive
data after the last byte has been transmitted from the tx fifo. The client
would need to lock the serial port in order to take advantage of this
feature so that no other clients try to read/write data with the “special”
port protocol settings applied. The client would also be required to restore
the original port protocol settings when finished usign the “special” mode.
Does anyone see any pitfalls/gotchas to this approach?
Does anyone have any other suggestions on a different approach to the
solution?
TIA
Rover Fan <RoverFan_SE7@hotmail.com> wrote:
I am in the process of writing a resource manager for a goofy RS-232 serial
communication application that requires (occasionally) that data be
transmitted at a particular baud rate and the reply data be received at a
different baud rate. I would like to implement the “standard” POSIX
interface. I have the char DDK and the io-char source from the QNX CVS
repository. The only solution I have come up with so far is to add a new
DCMD to allow a client process to specify a termios struct needed to receive
data after the last byte has been transmitted from the tx fifo. The client
would need to lock the serial port in order to take advantage of this
feature so that no other clients try to read/write data with the “special”
port protocol settings applied. The client would also be required to restore
the original port protocol settings when finished usign the “special” mode.
Does anyone see any pitfalls/gotchas to this approach?
You’d want to catch io_close_ocb callbacks, and make sure that you also
restore from “special” mode to normal mode if the client closes/disconnects.
You might want to disable io_dup() if in special mode. Not sure what
the side-effects of this would be.
Does anyone have any other suggestions on a different approach to the
solution?
This sounds reasonable to me.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
About locking I think it’s very easy to do inside the application by
adding a flag in the attribute structure.
Now, if we have to protect a serial port from other processes, it seem
that it’s not so obvious.
I try to do this with this piece of code, but I not really sure it’s
secure even if we consider that other processes only use posix API.
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = 0;
lock.l_len = 0;
fcntl(ser_datas_p->fd, F_SETLKW, &lock);
What do think og that David?
regards,
Alain.
David Gibbs a écrit:
Rover Fan <> RoverFan_SE7@hotmail.com> > wrote:
I am in the process of writing a resource manager for a goofy RS-232 serial
communication application that requires (occasionally) that data be
transmitted at a particular baud rate and the reply data be received at a
different baud rate. I would like to implement the “standard” POSIX
interface. I have the char DDK and the io-char source from the QNX CVS
repository. The only solution I have come up with so far is to add a new
DCMD to allow a client process to specify a termios struct needed to receive
data after the last byte has been transmitted from the tx fifo. The client
would need to lock the serial port in order to take advantage of this
feature so that no other clients try to read/write data with the “special”
port protocol settings applied. The client would also be required to restore
the original port protocol settings when finished usign the “special” mode.
Does anyone see any pitfalls/gotchas to this approach?
You’d want to catch io_close_ocb callbacks, and make sure that you also
restore from “special” mode to normal mode if the client closes/disconnects.
You might want to disable io_dup() if in special mode. Not sure what
the side-effects of this would be.
Does anyone have any other suggestions on a different approach to the
solution?
This sounds reasonable to me.
-David
Thanks for the input. Hadn’t considered the dup caveat 
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:apmse0$kvr$2@nntp.qnx.com…
Rover Fan <> RoverFan_SE7@hotmail.com> > wrote:
I am in the process of writing a resource manager for a goofy RS-232
serial
communication application that requires (occasionally) that data be
transmitted at a particular baud rate and the reply data be received at
a
different baud rate. I would like to implement the “standard” POSIX
interface. I have the char DDK and the io-char source from the QNX CVS
repository. The only solution I have come up with so far is to add a new
DCMD to allow a client process to specify a termios struct needed to
receive
data after the last byte has been transmitted from the tx fifo. The
client
would need to lock the serial port in order to take advantage of this
feature so that no other clients try to read/write data with the
“special”
port protocol settings applied. The client would also be required to
restore
the original port protocol settings when finished usign the “special”
mode.
Does anyone see any pitfalls/gotchas to this approach?
You’d want to catch io_close_ocb callbacks, and make sure that you also
restore from “special” mode to normal mode if the client
closes/disconnects.
You might want to disable io_dup() if in special mode. Not sure what
the side-effects of this would be.
Does anyone have any other suggestions on a different approach to the
solution?
This sounds reasonable to me.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
About locking I think it’s very easy to do inside the application by
adding a flag in the attribute structure.
Now, if we have to protect a serial port from other processes, it seem
that it’s not so obvious.
I try to do this with this piece of code, but I not really sure it’s
secure even if we consider that other processes only use posix API.
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = 0;
lock.l_len = 0;
fcntl(ser_datas_p->fd, F_SETLKW, &lock);
What do think og that David?
The problem with fcntl() for locking is that the file locks here
are advisory. They only help for other readers/writers that check
for locks before they read/write. It sure sounds like he wants to
lock out EVERYONE, not just nice programs.
For instance, cat doesn’t check for advisory file locks.
Also, locks are generally thought of as applying to files – not
to devices.
I think I prefer the devctl idea to the fcntl() idea.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.