Guys,
I haven't had a chance to look at what everyone has done but here are my
thoughts.
The major thing I have done with ioctls() is to do a nonblocking read
FIONREAD which also returns the number of bytes available for reading. I
could not find a similar function using termios. I can't think of a way
to avoid this. (I would actually like to go even lower and use
interrupts for notification as the polling is wasteful of resources.)
Also, I agree with the comment about removing the separate input and
output streams. It is just asking for problems. I was planning to look
at merging them but have not had the time.
Dave Atkinson
>
>
> On Sun, 20 Sep 1998, Sheldon Young wrote:
>
> > At 11:13 AM 9/20/98 -0600, Trent Jarvi wrote:
> >
> > >sheldon: I just sat down this morning (6 hours) and commented most
the
> > >SerialImp.c code to rxtx. its a 32k patch. does not mess with
code much
> > >at all. Should help people thinking about contributing/fixing
things. Is
> > >it ok to send it into the cvs?
> >
> > Thanks for asking. Go for it
>
> done.
>
> > >I notice there is still a fair amount of ioctl stuff in
SerialImp.c...
> > >like david says, its hard to find good sources of documentation on
ioctl
> > >and termios. I've marked them as FIXME till we can figure out how
to do
> > >it right with termios.
> >
> > Sounds good.
>
> I removed all the ioctls that are possible. I talked to some kernel
> hackers and it appears much of what david did has to be done with low
> level ioctls. I removed what we could.
>
> > >Strange... SerialImp.c which started as a 4k file is now 100k.
> >
> > Perhaps we should think about splitting it....
> >
>
> I think what may be best is to take a serious look at the duplication
of
> input and output streams. The kernel keeps that as one structure not
two.
> (I'm not sure what other unix's do though.) ie.. input and output
> streams are actually working on one termios at the kernel level.
>
> declaring
>
> struct termios in
> struct termios out
>
> and treating them seperate may actually be more confusing than need
be.
> change in and tcsetattr then change out and tcsetattr you end up with
> in==out at the kernel level. I think it was a design flaw on my part.
>
> david: Great work. Took a long time to read through and verify
> SerialImp.c changes. you can double check the changes I made but they
are
> minimal.
>
> I've found another hacker thats going to take a look at commapi (I
> personally dont use it so I have to trust you guys there). I'll let
you
> know if he bites. I think david's work got his attention.
>
