lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 18 Aug 2016 13:18:25 +0200 From: "H. Nikolaus Schaller" <hns@...delico.com> To: Pavel Machek <pavel@....cz> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Marcel Holtmann <marcel@...tmann.org>, Rob Herring <robh@...nel.org>, Jiri Slaby <jslaby@...e.com>, Sebastian Reichel <sre@...nel.org>, Peter Hurley <peter@...leysoftware.com>, NeilBrown <neil@...wn.name>, Arnd Bergmann <arnd@...db.de>, Linus Walleij <linus.walleij@...aro.org>, linux-bluetooth@...r.kernel.org, linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org, herkne@....de Subject: Re: [RFC PATCH 0/3] UART slave device bus > Am 18.08.2016 um 13:10 schrieb Pavel Machek <pavel@....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. > > Actually, having some kind of common support for GPSes in the kernel > would be nice. (Chardev that spits NMEA data? Yes and no. How do you apply tcsetattr to such a device? More or less by implementing another tty stack? > ) 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. 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. Still user-space should be able to tcsetattr how it wants to see the records (mainly CR/LF translations). BR, Nikolaus
Powered by blists - more mailing lists