Alan Cox wrote:
The Linux serial driver is an abomination in itself (the only saving grace is that it's largely compatible back to the days of the ASR33 teletype machine).

We do 2Mbits/sec quite happily.

I'm not referring to speed, I'm referring to the incredible set of serial options that user-space needs to wade through, and presumably the drivers need to support in some form or another. Many of these options date back to the days of mechanical terminals and devices such as the ASR33 and the almost-as-old Decwriters (things like inter-character delays, etc). I think compatibility is a good thing, but if we were to do it again, would all of that really be in the kernel?

IMO, if performance is the goal, we need to consider a custom high-speed serial driver for the UART connected to the GSM, one that gets rid of the overhead of the entire tty layer in the kernel.

What overhead. If you are driving the tty layer properly on a modern
kernel you should have almost no overhead from the tty layer. If not
collect profile traces from 2.6.24 or later, gprof them, produce the
graphs and file a bug.

What overhead, you ask? The overhead of handling everything a character at a time! I have no doubt that with enough CPU dedicated to the task, one can achieve remarkable throughput. But I think that's unnecessary overhead especially for when dealing with protocols that are not character-at-a-time. I doubt that the type of driver I mentioned in the original email would be very useful for a console, but that's not the problem I'm considering; I'm speaking of high-speed devices moving lots of data serially in high-latency environments, using modern UARTs capable of DMA. Leave the console on the existing driver; but have an alternate that makes the best use of the hardware to move large amounts of data with the smallest CPU and lowest clock speeds possible.

No bugs are necessary to file; the current serial driver works for what it was intended to do; I'm suggesting a driver for things that the current serial driver was *not* intended to do.

Alan

Mike (mwester)

Reply via email to