Am 18.08.2016 um 13:49 schrieb Marcel Holtmann [off-list ref]:
=20
Hi Nikolaus,
=20

quoted

quoted

quoted

quoted

I am actually not convinced that GPS should be represented as
/dev/ttyS0 or similar TTY. It think they deserve their own driver
exposing them as simple character devices. That way we can have a
proper DEVTYPE and userspace can find them correctly. We can also
annotate them if needed for special settings.

=20
I would _love_ to see that happen, but what about the GPS line
discipline that we have today?  How would that match up with a char
device driver?

=20
./drivers/usb/serial/garmin_gps.c ?
=20
Hmm, some cleanups would be welcome there... plus it would be good =

to

quoted

quoted

know what is its interface to userland... it is not easily apparent
from the code.
=20
Actually, having some kind of common support for GPSes in the kernel
would be nice. (Chardev that spits NMEA data?

=20
Yes and no. How do you apply tcsetattr to such a device? More or less
by implementing another tty stack?
=20

quoted

) For example N900 GPS is
connected over network (phonet) interface, with userland driver
translating custom protocol into NMEA. Not very nice from "kernel
should provide hardware abstraction" point of view.

=20
Indeed. In such a case the translation should be done in the kernel.
But it is not necessary for devices that already provide NEMA over =

UART.

quoted

Still user-space should be able to tcsetattr how it wants to see the =

records

quoted

(mainly CR/LF translations).

=20
I disagree here. NMEA is a standard and the kernel should just enforce =

framing of NMEA sentences.

AFAIR, NMEA was originally sort of a serial bus going through a ship. =
Where masters (a gps receiver)
can send records with position and speed data and clients (e.g. an =
auto-pilot) can receive them and
process their actions and send control commands to a motor / winding =
engine. But I would have to do
more research about this.

It makes no difference what the CR/LF is. Userspace gets full =

sentences.

NMEA defines that devices connected to the NMEA source receive =
characters and not sentences.

For example an NMEA record defines a checksum. Should that also be =
exposed to user space or hidden?
How should checksum errors be reported or handled by the kernel?

I would agree if we want to write an abstract "position in geospace" =
driver/subsystem which reports
the position on surface and height and speed and direction. Then we can =
hide everything in the kernel.
But this would no longer send sentences to user space but cooked =
coordinates. More like iio data.

And next issue: how should we handle GPS devices with a bidirectional =
interface where sending
some special command sequence over the UART switches to SIRF or some =
other proprietary
mode? Then, the driver (ans Linux) can't squeeze that into NMEA =
sentences any more. By
doing this in the kernel we make it more inflexible.

Puh, when digging into this topic it becomes more and more complex and =
we are making it more
complex than it is currently working.

BR,
Nikolaus