linux-kernel - Re: [PATCH 0/7] gnss: add new GNSS subsystem

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]

Date:   Tue, 24 Apr 2018 22:59:48 +0200
From:   Andreas Kemnade <andreas@...nade.info>
To:     Pavel Machek <pavel@....cz>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Arnd Bergmann <arnd@...db.de>,
        "H . Nikolaus Schaller" <hns@...delico.com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/7] gnss: add new GNSS subsystem

On Tue, 24 Apr 2018 22:13:19 +0200
Pavel Machek <pavel@....cz> wrote:

> Hi!
> 
> > This series adds a new subsystem for GNSS receivers (e.g. GPS
> > receivers).  
> 
> Actually... I'd just call it GPS subsystem. Yes, GPS is a bit
> misleading, but so is GNSS. We'd like Loran to use similar interface,
> right? We'd like to QZSS to use similar interface, too...
> 
> https://www.pcworld.com/article/205325/japan_launches_its_first_gps_satellite.html
> . QZSS is not _global_ positioning system. Still they call it GPS. I'd
> call it GPS too.
> 
> (Alternatively, we could have drivers/position and /dev/pos0...)
> 
> Looking closer... I'm not sure if it makes sense to push different
> protocols (SiRF, NMEA, ...) through one device. Userland should know
> what protocol to expect... Yes, there will be common code between
> /dev/nmea0 and /dev/sirf0...
> 
> I don't know. I'd really like to see '/dev/input/event0'-like layer,
> so that userland would not need to know about different protocols. But
> your work solves some problems we have now...
> 
I am not really sure what to do here. The question is if we can remove
nmea parsing from userspace if the kernel does it? There is the
use-case of having external loggers storing nmea data and userspace
will access the logger data and needs to have nmea parsing for that
anyway.

But for other more exotic stuff, it would be helpful that the user
space does not need to handle the differences.

Hmm, maybe userspace could register something like uinput devices for
having more complex calculation. Maybe triangulating using gsm cell
reception data. And the uinput-like device would have properties
attached like accuracy, costs.

Regards,
Andreas

Content of type "application/pgp-signature" skipped