Re: [RFC PATCH 0/3] UART slave device bus

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >>> 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.
>

Aha.

> > 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.
>

Yep, that would	make sense, one	day. (Another discussion is if NMEA is
the right protocol to use for kernel<->user interface, esr has some
rather good reasons to believe it is not. But that, too, can wait...)

Anyway, whatever works for bluetooth is likely to work for future gps
subsystem, so we should be ok here. And having support for serial
devices (not pretending they are platform) is a good step forward.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html