Hi Johan,

Am 19.03.2018 um 14:54 schrieb Johan Hovold [off-list ref]:

On Tue, Feb 27, 2018 at 08:32:50AM +0100, H. Nikolaus Schaller wrote:

quoted

Hi Johan,

quoted

Am 27.02.2018 um 08:04 schrieb Johan Hovold [off-list ref]:

On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote:

quoted

Hi!

quoted

quoted

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.

quoted

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