Hi Johan,
Am 19.03.2018 um 14:54 schrieb Johan Hovold johan@kernel.org:
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).
Ok, that would be fine if we can get that!
For a minimal set of API I think something like this (following hci_dev) would suffice:
struct gps_dev { ... int (*open)(struct gps_dev *gdev); int (*close)(struct gps_dev *gdev); int (*send)(struct gps_dev *gdev, char *data, int length); };
int gps_register_dev(struct gps_dev *gdev); void gps_unregister_dev(struct gps_dev *gdev); int gps_recv_nmea_chars(struct gps_dev *gdev, char *data, int length);
If that would wrap all creation of some /dev/ttyGPS0 (or however it is called), it would fit our needs for a driver and user-space for our system.
And I would be happy to get rid of creating and registering a /dev/ttyGPS0 in the w2sg0004 driver.
Then, the driver will not need to be touched if the GPS framework is improved in some far future (e.g. to provide some additional ioctl for getting kalman-filtered position+heading by doing sensor fusion with some iio-based accelerometer/gyro).
So I am looking forward to some framework for review and integration testing.
BR and thanks, Nikolaus