Wed 09 May 2012 02:29:27 PM UTC, comment #4:
It is out of scope for GPSD, but that is why I'm suggesting forking it out as a separate project with some transition, since you consider it critical to probe for GPS units on any generic serial port and don't care about any other software, hardware, or project that this might damage or cause trouble.
If GPSD is turning into malware as far as serial ports are concerned, it is within scope. If you aren't going to create something that fixes the general case, then you need to fix GPSD at whatever level to make it easy to find and disable the bad behavior.
Probing generic serial ports for GPS might be a good default option but it should be a proper option.
If when I installed the Arduino environment, it would make a UDEV entry that would launch the environment any time a generic FTDI was inserted, I would consider that stupid even if it didn't grab the port and start sending junk out. I consider GPSD doing worse things at least equally stupid. You should do it properly - at least enough to mitigate damage - or not at all.
1. GPSD does not cache or learn and the probe is minimal dumb brute-force. If I insert a generic device 100 times but never a GPS, you probe the device each and every time. A second device will be probed even if there already is a running GPS attached. There is no intelligence to either the launch or the probe which is why I call it stupid.
2. You provide no easy, documented way to disable this. The behavior is not (easily?) found in GPSD OR ITS DOCUMENTATION, but buried in some system CONFIGURATION FILES not part of GPSD. GPSD does use configuration files, but not its own, it uses and alters the system configuration files instead.
3. The probes are long and intrusive and I don't think it puts the port back where it found it so it doesn't even clean up after itself.
4. It locks the port and holds it for a long time - several seconds - where I can't talk to it or launch anything. There are no quick "oh, it is NOT a GPS, lets exit" things at the top, so although it might figure out in 10mS it is not a GPS, you are going to spend 10 seconds trying every combination of baud rates and probes for every possible GPS with a generic chipset and not let go.
5. You've done this on a hunch, not on any statistical analysis - maybe it is only 5 noobs with cheapo GPS units v.s 1000 Arduino users (and they buy that to learn open source software and hardware so not everyone is a hacker, and I know a lot and it took me a long time to find and fix). There may be more critical hardware that breaks.
6. Even if I fix it today, if there is a package update, it will reinsert the offending lines (and maybe some new ones). There is no way of doing this as either a build or install option (exclude probes on generic devices). It doesn't even have memory across installs. If I manually alter a configuration file, it should keep my alterations or note that it is reverting them.
You consider the above a "smart" or elegant way of doing things?
|