> [TTY-Devces 4 / 5]
> I just want underpin this request. I asked the very question a couple of times
> but noone could give a resonable answer about this topic. Instead I recently
> got a getty-implementation in my hands, where was said:
> "... on LINUX use the ttyS-devices not the cua-devices. No, I'm not
> willing to disuss this here ..."
Well, obviously you're talking about mgetty+sendfax.
Seems that I have to explain it a bit now... - mgetty+sendfax allows
dial-out and dial-in on the same line, and manual answer of the phone. If
you use ttyS for mgetty and cua for sendfax, sendfax will fail with EBUSY.
If you use cua for mgetty, programs will mysteriously fail because there's
no controlling tty on /dev/cua devices.
If you use ttyS for both programs, it works.
Quote:> Just great! The whole thing did not work with ttyS-devices at all -- but is
> working just fine with a cua-device now ... bewildering!
Well... all linux systems *I* have installed mgetty+sendfax so far, it
worked on ttySx. It did *not* work on cua (did ya ever get a complaint
from bash about unavailable job control? That's what will happen if you
use a getty program on /dev/cua).
And please cut the *about "flow control not working on /dev/ttyS". The
kernel doesn't differenciate *at all* between /dev/ttyS and /dev/cua
except when opening the device and assigning a controlling tty (or not
doing so). All flow control / data i/o stuff is completely independent of
Oh... btw... if you cite from my documentation and tell later on that it's
*and what I write is wrong, why don't you tell *ME* what problems
Quote:> "Undocumented software is shitware!"
> The point is that the manual section 4 (devices) is nearly empty. It seems
> that people who write device drivers think, that they did a great job, when
> their driver is doing fine just FOR THEM and some others who could follow the
> development -- others are kept standing in the rain!
Well, listen, guy: the linux developers do that *for free*. If you pay me,
I'll write you every manpage that you want. If not, write it yourself.
What, you don't know about anything about the Kernel? Then read the
Quote:> Listen all you guys out there, who provide us with software of any kind for
> LINUX: We (the community) can't read your brains. So you got to write it
> down, what you indented with your code, its implemetation and the way it is
> to be integrated.
Well, you don't have to read the brains, it's enough to read the source.
That's what you have it for. The source is the ultimate, ever-correct,
ever-up-to-date documentation anybody can wish.
Quote:> If there is anything wrong with LINUX, it is its documentation.
> - where are the man-pages fd(4), hd(4), sd(4), rmt(4) etc.?
> - where is explained that LINUX does not know 'raw'-disks and why?
> (a.s.o, a.s.o)
Who needs to know that? If you really need to know, look into the kernel.
Quote:> I'm just asking for keeping me from asking stupid questions.
Ok, then take a weekend off, read all the kernel source, and stop whining
that somebody else should ease your life instead of improving the linux
sources. That's more important than documentation.
I've got a signature breakdown! Anybody got a spare one?