line BRK detection on ttyS0

line BRK detection on ttyS0

[Mark Hounschell]

Does the kernel support sending a SIGINT from a line BRK on ttyS0 to a thread of a process
where the process has a controlling terminal that is NOT ttyS0 and the thread is using ttyS0
in a cfmakeraw mode? I see doc that implies that ttyS0 must be the controlling terminal but
can my thread have a controlling terminal while my main process has it's own? My thread
cannot use the \377 \0 \0 char sequence because it is receiving and transmitting 8-bit binary
data. Is there a way for the kernel to inform my thread, not my main process, of a line BRK?
Or a way for my thread to ask the kernel if a line BRK occurred on ttyS0?

Thanks and regards
Mark

Re: line BRK detection on ttyS0

[Alan Cox]

On Wed, 22 Sep 2010 15:36:48 -0400
Mark Hounschell <markh@compro.net> wrote:

> Does the kernel support sending a SIGINT from a line BRK on ttyS0 to a thread of a process
> where the process has a controlling terminal that is NOT ttyS0 and the thread is using ttyS0
> in a cfmakeraw mode? I see doc that implies that ttyS0 must be the controlling terminal but
> can my thread have a controlling terminal while my main process has it's own ?

If they have two different ttys open then yes at least as far as Linux is
concerned. I don't know how glibc handles it as it can do signal groups
and the like and delivery of signals to process not threads etc.

You can see parity anyway. In PARMRK mode you get \377 \0 [whatever] for
parity/break etc but \377 is also doubled for a real one - ie \377 \377

Alan

Re: line BRK detection on ttyS0

[Mark Hounschell]

On 09/22/2010 08:03 PM, Alan Cox wrote:
> On Wed, 22 Sep 2010 15:36:48 -0400
> Mark Hounschell <markh@compro.net> wrote:
> 
>> Does the kernel support sending a SIGINT from a line BRK on ttyS0 to a thread of a process
>> where the process has a controlling terminal that is NOT ttyS0 and the thread is using ttyS0
>> in a cfmakeraw mode? I see doc that implies that ttyS0 must be the controlling terminal but
>> can my thread have a controlling terminal while my main process has it's own ?
> 
> If they have two different ttys open then yes at least as far as Linux is
> concerned. I don't know how glibc handles it as it can do signal groups
> and the like and delivery of signals to process not threads etc.
> 
> You can see parity anyway. In PARMRK mode you get \377 \0 [whatever] for
> parity/break etc but \377 is also doubled for a real one - ie \377 \377
> 

\377 \0  or  [whatever] just looks like valid data to my thread though.
So you're saying it's gonna be a glibc thing and not a kernel thing that
prevents my thread from getting a signal?

Thanks
Mark

Re: line BRK detection on ttyS0

[Alan Cox]

On Thu, 23 Sep 2010 16:48:14 -0400
Mark Hounschell <markh@compro.net> wrote:

> On 09/22/2010 08:03 PM, Alan Cox wrote:
> > On Wed, 22 Sep 2010 15:36:48 -0400
> > Mark Hounschell <markh@compro.net> wrote:
> > 
> >> Does the kernel support sending a SIGINT from a line BRK on ttyS0 to a thread of a process
> >> where the process has a controlling terminal that is NOT ttyS0 and the thread is using ttyS0
> >> in a cfmakeraw mode? I see doc that implies that ttyS0 must be the controlling terminal but
> >> can my thread have a controlling terminal while my main process has it's own ?
> > 
> > If they have two different ttys open then yes at least as far as Linux is
> > concerned. I don't know how glibc handles it as it can do signal groups
> > and the like and delivery of signals to process not threads etc.
> > 
> > You can see parity anyway. In PARMRK mode you get \377 \0 [whatever] for
> > parity/break etc but \377 is also doubled for a real one - ie \377 \377
> > 
> 
> \377 \0  or  [whatever] just looks like valid data to my thread though.

If you have PARMRK mode set then you need to parse the data stream. If
you see \377 \0 then you know it is control information because any \377
received from the other device will be passed to you as \377\377

> So you're saying it's gonna be a glibc thing and not a kernel thing that
> prevents my thread from getting a signal?

I'm saying you need to ask glibc people - I'm not sure exactly how they
set up the posix signals for threads, and posix thread signalling is
fairly demented.

Alan