On Tue, Feb 27, 2018 at 08:32:50AM +0100, H. Nikolaus Schaller wrote:
Hi Johan,
Am 27.02.2018 um 08:04 schrieb Johan Hovold johan@kernel.org:
On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote:
Hi!
Let's restart this discussion and focus on the main roadblock (others are minor details which can be sorted out later).
If it feels like a hack, the key issue seems to me to be the choice of the API to present the GPS data to user space. Right?
Or even more fundamentally, does this belong in the kernel at all?
Yes, it does.
Thanks, Pavel for supporting our view.
But not necessarily in its current form.
Is this a "yes after some code fixes"?
No, we need some kind of at least rudimentary gps framework even if we allow for a raw (NMEA) interface for the time being (possibly indefinitely).
Pavel mentioned an example where such an evolutionary approach was taken.
Now, if we'd ever have a proper GPS framework that handled everything in kernel space (i.e. no more gpsd) then we would be able to write kernel drivers that also take care of PM. But perhaps that's unlikely to ever be realised given the state of things (proprietary protocols, numerous quirky implementations, etc).
That is what needs to happen.
The kernel is probably not the place to be working around issues like that, even if serdev at least allows for such hacks to be fairly isolated in drivers (unlike some of the earlier proposals touching core code).
Oh, kernel is indeed right place to provide hardware abstraction -- and that includes bug workarounds.
Right, at least when such hacks can be confined to a driver and not be spread all over the place.
It seems that you forgot that the driver we propose is not spread all over the place. It *is* confined to a single driver thanks to the serdev api.
I believe that's what I wrote above.
Johan