Hi Pavel, >>> 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. >> >> 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? > > ./drivers/usb/serial/garmin_gps.c ? > > Hmm, some cleanups would be welcome there... plus it would be good to > know what is its interface to userland... it is not easily apparent > from the code. however that driver is not a line discipline. That is just an USB driver. But I agree if we create a GPS driver framework / subsystem, then this one should be converted into using it. > Actually, having some kind of common support for GPSes in the kernel > would be nice. (Chardev that spits NMEA data?) 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. I agree that if we just had a dedicated GPS NMEA char device, then that would be great. However we might just add an additional /dev/unmea like /dev/uinput, /dev/uhid, /dev/vhci. It could be used for unit testing and also hardware where the protocol is in userspace in the first. Like the mentioned QMI or some Intel AT command based modem. We would then just convert oFono to create the /dev/unmea device for us. The advantage is that then even userspace NMEA device are part of the device tree and enumerated by udev. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
