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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <A8AFECE4-8501-4186-A834-5E08EEE8A0C4@goldelico.com>
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