Re: [gpsd-dev] [PATCH] Bump GPS_PATH_MAX to allow using persistent names.

[Eric S. Raymond]

tz <address@hidden>:
> Note that this full devicename path is included in the JSON output to
> identify the source.
> 
> (This was discussed before, and I suggested some ordinal or the file number
> returned by open or something, and I said it would bite - there can also be
> duplicates, e.g. TCP or UDP connections).

My main reason for rejecting this proposal was that I didn't want the bugs
and maintainence issues associated with implementing yet another layer of
indirection inside gpsd.

Also, I dislike throwing identifying data away for any reason.  If I
ever do that, it is inevitable that some day a client-side programmer
will curse me bexcause this attempt to optimize for shorter transmission
length (or whatever) has stepped directly on his weird use case.  Or
not so weird, even - imagine a gpsd instance connected to several 
RS232 devices with stable names.

I think both these objections are still sound. 

> There is no speciific reason to have to know or store a system defined file
> path after the device node is opened, but it is being used as part of the
> data.

Think of it as the simplest possible identifying cookie for the
device.  Not perfect, but the thought of adding an obfuscating layer
to manage a GPSD-private namespace of magic device-identifying cookies
instead strikes me as, well, perverse - not merely asking for trouble,
but begging for it on bended knees.

> You are changing it to 128 now, but it might need to be 256 later, e.g. the
> dev path might get vary long if it models the USB device bus tree and
> includes this.  There is no static limit to a full path name, so the real
> alternatives are to malloc it (if you are going to store it and not just
> point to argv or something) or to store something else.

This completely fails to bother me.  It's not 1985 any more.  Memory
is cheap, gpsd's data rates are low, and all the economics that said
JSON was a good idea also tells us that trying to micro-optimize this
sort of thing would be just stupid.  A few more 1024-character buffers
would not be a large price to pay.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>