lkml.org 
[lkml]   [1996]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Bug in serial line hangup code ?
Date
"Andrew E. Mileski" <aem@nic.ott.hookup.net> wrote:
> > ppp enables hangup, and on hangup closes the port. The serial driver
> > sets info.count to 0 on hangup, even though my program still has the
> > port open. As my program watches info.count to determine if another
> > process has the line is open, this is a bit of a problem.
> >
> > This is the way the serial driver is *designed*. Once a hangup has
> > occurred, programs do not logically have the port "open". Access to the
> > file descriptors has been revoked, and so they no longer can read or
> > write to the serial port.

> PMFJI, if I recall the start of the thread (I may be completely wrong),
> the idea is to allow serial port monitoring? Why not just have the
> info available via /proc/serial/0 (or whatever)?

> A simple tagged format like:
> CTS: Active
> RTS: Inactive
> DTR: Active
> DSR: Inactive
> DCD: Inactive
> RX Buffer: 0
> TX Buffer: 0

How about: because my latest patches only add about a dozen bytes to the size
of the kernel, whereas a /proc interface would add much more.

How about: as my program that does the screen update looks at the data
every 50ms (to make the data LEDs look right), the overhead of reading and
processing the /proc format would be a much bigger load. It seems ridiculous
to execute code in the kernel to convert a binary number to an ascii string,
then convert it back in user land, when the number can be accessed directly
through an IOCTL. (Which would be possible even if someone does add a /proc
interface).

--
Peter Fox


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.081 / U:1.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site