Falling through the cracks: why GPSD sometimes bogarts non-GPS devices

In a recent Google+ comment, H. Peter Anvin grumped about GPSD using “braindead heuristics” to determine which USB devices it should sniff as possible GPses when it gets a hotplug notification saying that one has connected. I was going to reply in a comment there, but the explanation ran too long for that.

Short version: yes, GPSD will very occasionally sniff at a device that is none of its business. We’re stuck in a bad place because of deficiencies in the USB standard, But it doesn’t happen often, and all the alternative behaviors I’ve been able to imagine would be worse in very obvious ways. Detailed explanation follows.

USB devices are supposed to present a “device class” number that clues in the host system what kind of thing it is and how to talk to it. In an ideal world, there would be a “GPS” device class which every GPS would present, and GPSD would cheerfully ignore anything that didn’t present it, and all would be gladness and joy.

We don’t live in that world. Look at the list of USB device classes and notice that none of them is “GPS”. Lacking any defined GPS class, the standard tells vendors that GPSes have to sit in the stupid corners labelled “00h” and “FFh”. Along with every other USB devices type lacking an assigned class number, including in particular serial-to-USB adapter chips.

You may recall from some of my previous rants that your basic bog-standard USB GPS consists of a GPS chip shipping data over TTL-level RS232 lines to a serial-to-USB adapter chip. And that’s the root of GPSD’s problem right there. GPSD will never mess with your mouse or your mass storage but here’s no way that a USB GPS is distinguishable from some random other device that happens to be lurking behind a serial-to-USB adapter – it’s classes 00h/FFh all the way down.

So GPSD goes to the next level and watches for the specific Vendor-ID/Product IDs of serial-to-USB adapters that usually mean aha that’s a GPS. The most common VID/PID combination is 067b:2303 which is a Prolific Logic 2303; GPSD also recognizes nearly a dozen other specific VID/PID pairs mostly corresponding to various serial-to-USB adapter chips.

And 99% of the time “that’s a GPS” is exactly what these VID/PID pairs do in fact mean; for end users, anyway. The exceptions are things like Arduino prototyping boards that will only ever be hooked up by a tiny minority of geeks like…H. Peter Anvin. Who will grumble.

This sucks in a minor way, but watcha gonna do? With this behavior. GPSD has very nice autoconfiguration in almost all cases – you plug in the GPS, hotplug wakes up the daemon, it autobauds and autoconfigures, and location data magically appears on port 2947 without the user having had to hand-tweak a blessed thing. This is good!

Unfortunately, the only way to prevent GPSD from occasionally sniffing at a device that turns out not to be a GPS would be to disable hotplug startup and require users to manually launch GPSD when they want to run it and know what their device inventory is. This would end the muttering from people like H. Peter Anvin, but at the cost of requiring hundreds of thousands of bewildered end-users to hand-lunch GPSD and remember details like device names, rather than having things Just Work.

This would not, in my view, be an acceptable tradeoff. This is one time I’m afraid I have to tell the hard core to live with the occasional glitch; greatest good for the greatest number and all that. Even adding a GPS class to the USB standard wouldn’t solve the problem at this point – too many GPSes already fielded, and many of the vendors are such sketchy low-margin operations that it’s not clear they’d add the production step to do the right thing even if it were available.

UPDATE: Several commenters had the usual Unix-programmer reaction: just add a config switch! They’re not thinking the problem through; no config switch can solve enough cases to be worth the freight.

One very common suggestion whenever this comes up is a blacklist option for particular VID/PID pairs, like –no-probe=067b:2303. The trouble with this is that there are too many different devices using so few different USB-to-serial adapters, and this option would only be useful when you have multiple class 00/FF devices using different VID/PID pairs. In particular it’s quite likely that your GPS and your serial-port adapter dongle will both be using a PL2303, so blacklisting by VID/PID will make both invisible.

Another common but futile suggestion is blacklisting by device path. USB device-path assignments aren’t stable in the presence of hotplugging, enough said.

Not only isn’t there enough information for autoconfiguration to work perfectly, the same missing information makes it (so far) impossible to specify a config option that I judge to be than a feel-good gesture or wishful thinking.

Also, people looking at this problem often jump to the conclusion that the failure cases are much more frequent and dangerous than they actually are. GPSD typically is not sending config strings to random devices it hasn’t identified as GPSes yet; it’s just sniffing data, and only immediately after a hotplug event. The worst case is that another class 00/FF loses a second’s worth of data, not that it gets accidentally told to self-destruct or something.

UPDATE2: Another safeguard, which I had forgotten writing, is that under Linux GPSD uses a sadly non-portable hack which determines if a device has been opened by another process and if so ignores it. So the only way gpsd even reads from an unknown device is when no other application has claimed it.

113 comments

  1. Touching random serial devices is dangerous. In this case, it is not a proto board, but a bog standard serial-usb cable.
    There is a lot of space between “user needs to configure device names” and “gpsd grabs serial ports away from other software”. For one, a button with “connect to GPS” (and then remembering that the user HAS a gps) takes care of the majority: Until the user wants to use a GPS device and tells you there is one somewhere… you’re not talking to the UPS to turn the machine of… e.g. only those people who get the gain (e.g. have a GPS) take the pain of the risk.

  2. This is all academic to me since I don’t have a (flip flip) GPS device for my computer anyway. I er… Like what the Navstar is a GPS, anyway?

    Eric, did this post come about as a result of your BufferBloat(tm) timing device/synchronization PPS efforts?

    1. >Eric, did this post come about as a result of your BufferBloat(tm) timing device/synchronization PPS efforts?

      No. Reread it, since I explained exactly where it came from in the first paragraph.

  3. “Unfortunately, the only way to prevent GPSD from occasionally sniffing at a device that turns out not to be a GPS would be to disable hotplug startup and require users to manually launch GPSD when they want to run it and know what their device inventory is.”

    So, put a flag in the config file that can disable hotplug startup.

    Of course, this might also require the UI to manually launch GPSD which might well be non trivial.

    1. >So, put a flag in the config file that can disable hotplug startup.

      Config file? What config file?

      GPSD doesn’t have a config file. By design. That kind of lazy thinking – oh, I can’t be arsed to figure out the right thing, I’ll just add a config switch instead – is exactly the shit I worked hard at moving the design away from.

  4. You’ve got a config file though, where geek users can write “don’t touch these devices (list of IDS)”, rigth? And a “no-touch sniff” command line which lets them see candidates so they know which to add to said file?

  5. Ha! Beaten to the punch.

    Working out-of-the box without a config file is a great design goal. But some scenarios can only be handled with config – if you encounter one of those you have to move to “config optional”.

  6. Oh,but you have several config files – in places like the udev directory, sobecause you don’t want to have one to fix gpsd, I have to mess with deep system files and arcane parameters.

    The other approach would be to simply declare a GPS that didn’t bother to get its own vid/pid broken and insist the user manually enable them. It is arrogant to have gpsd own the system, and it can be any peripheral, not just Arduinos. It isn’t 99%,but a fraction of a percent of GPS units that are broken. And many should be streaming NMEA or similar without any probing -you can’t passively listen instead of sending junk over the line at muktiple baud rates?

    You don’t test every bluetooth connection as soon as it is plugged in – the user needs to manually say it is a GPS.

  7. tz: You’d be declaring substantially every GPS device – and certainly all of the inexpensive ones – broken that way. They may all indeed be broken, but in the real world, all that does is make you irrelevant.

    If you don’t have GPS devices, don’t run gpsd in the first place. Of course, this means that Linux distributions need to move away from an install-the-world mentality…

    I do agree, though, that gpsd should be able to use a configuration specified in some optional manner – but in the absence of configuration data, I’ll agree that the current approach is the correct one to take. There are three possibilities: either you have a GPS device alone, a GPS device and another non-GPS device that uses the same ID as one that gpsd recognizes, or no GPS device. Only in the second case is there a problem, and that case is rare.

  8. GPSD doesn’t have a config file. By design. That kind of lazy thinking – oh, I can’t be arsed to figure out the right thing, I’ll just add a config switch instead – is exactly the shit I worked hard at moving the design away from.

    Having no config file and ASS|U|MEing that your auto-configuration is the best for everyone is the kind of colossal arrogance one normally finds only in government bureaucrats.

    Do note that I’m not objecting to trying to come up with reasonable defaults here. My objection is to not giving users a way to opt out of the defaults.

    It’s not a question of you “figuring out the right thing” because there is no “right” way to auto-configure these bastards. You can only detect a class of devices that you know includes some with which any attempt to communicate will bork them. It is therefore incumbent upon you to provide some mechanism by which users can configure GPSD to not bork those devices. It could be a config file that under normal circumstances need not even exist, a command-line option
    gpsd --no-probe=067b:2303
    or an envar
    export GPSD_NO_PROBE=067b:2303
    but there has to be some way to tell GPSD not to touch that particular Vendor ID/Product ID.

    HPA is right on this, and you’re wrong. If this were anything other than your project, say, TSA screeners who do the right thing 99% of the time and only occasionally do body cavity searches on four-year-old girls, you’d not be belittling their parents for complaining about it; you’d be leading the charge against it.

    Climb down off your high horse of ideological purity and recognize this situation sucks, and the best you can do is give people options on how to handle the suckage based on knowledge they have and you can’t possibly have.

    1. >but there has to be some way to tell GPSD not to touch that particular Vendor ID/Product ID.

      You’re making two wrong assumptions here. I think rather than write a long comment I’m going to update the post with an explanation.

  9. Haha. I came here just to post, ‘add a config switch’, knowing the reaction would be what it was. (I think that’s called trolling, but I’m not sure.)

    I’m not an expert or anything, but if there is the potential to damage shit by this auto-sniffing, I do see the potential for pain-in-the-neck of having an option (somewhere) is outweighed by the possibility of $$$.

    But, you know, if it is such a big problem, someone else can always add that option. So long as that part of the code does not change too much version to version, it shouldn’t be too hard to keep the patch relevant.

  10. > Config file? What config file?

    This is a great plan if you can always do the right thing automatically. However, evidently you can’t, so a good solution would be — do the right thing automatically in absence of a config file, otherwise do the right thing automatically, but allow tweaking of that automated process by a manual configuration mechanism.

    That way it works for grandma (who does nothing) and Peter Anivin, who does out of band stuff, but is probably smart enough to handle a little config file.

    However, you would be absolutely correct to make the slippery slope argument. Config files are indeed places to park unresolved design decisions from a development team.

  11. Rather than vendor:product pairs, the filtering option that immediately suggested itself to me was by serial number: This would require some setup on the user’s part, but as you point out, users who are using both gpsd and other USB-serial devices can be expected to handle it.

    What’s not okay is to simply declare that not having some way to correct gpsd’s mistakes is fine and dandy. I am reminded of the early days of mobile Web access, when I would visit some site with my (comparably powerful) phone, get redirected to a half-baked mobile version without the functionality I needed, and find that I was trapped on it with no escape hatch. It was infuriating, more for the hubris of the designers even than the inconvenience itself. *Any* system that’s going to go out and produce potentially harmful side effects in the name of convenience *must* provide some way for the user to turn off malfunctioning DWIM.

    1. >What’s not okay is to simply declare that not having some way to correct gpsd’s mistakes is fine and dandy.

      Lots of people say this. Not one has come up with a “correction” that I consider more than a futile feel-good gesture, an assentially meaningless obeisance before the idol of configurability. Maybe you will be the first, but I’m not optimistic. I’ve been grappling with this problem for years.

  12. Dismissal of Arduino boards as “something only gurus use” is a mistake. The stated goal of the Arduino project is to bring programming and robotics within the reach of artists, laypeople, and even children. By making these boards fail under mysterious circumstances, you are sabotaging that effort.

    That being said, I believe Arduinos speak their own very specific language back at you if you talk to them, and you could check for that.

  13. I see that gpsd does use libusb. Is this for both discovery and communication, or does it go straight to the tty once it finds a matching device?

    1. >I see that gpsd does use libusb. Is this for both discovery and communication, or does it go straight to the tty once it finds a matching device?

      Used for discovery only. I can explain why if you need me to, but I’m pressed for time right at this moment.

  14. > Not one has come up with a “correction” that I consider more than a futile feel-good gesture, an assentially meaningless obeisance before the idol of configurability.

    Am I correct in my interpretation that you consider any means of providing a device blacklist to gpsd at runtime is a “meaningless obeisance”?

    1. >Am I correct in my interpretation that you consider any means of providing a device blacklist to gpsd at runtime is a “meaningless obeisance”?

      Explain how you would do it. We already know blacklisting by VID/PID won’t solve the overwhelmingly common case of “everything is a PL2303”, and we know device paths aren’t stable. So what would your hypothetical device-blacklist option do, exactly? Don’t just insist that there’s gotta be a way, specify semantics.

  15. I’ve actually already done some moderate munching on similar issues in the context of routing USB devices to VMs. I have a couple of ideas, neither of which will Fix Everything, but both of which might go some way toward mitigating malfunctions. (Of course, one potential method is to try to get the Arduino and other device-kit manufacturers who present as USB serial to implement a “safe” “I’m-not-a-GPS” query at the kit level.)

    We already know blacklisting by VID/PID won’t solve the overwhelmingly common case of “everything is a PL2303?, and we know device paths aren’t stable.

    First, the unstable-device-path issue is a bug in a distro’s udev rules. Network device names have been stabilized through hotplug reactions to new devices for quite some time now, and such options as by-label/by-uuid block devices are now standard. ttyUSBx simply needs the same treatment as ethx. That said,

    1. Subject to how much complexity you’re willing to introduce, it should be possible to have a single hook point between where gpsd notices a device through hotplug/libusb and where it initiates the active scan (e.g., a boolean-valued function taking the struct for “discovered device”). Given that hook, a user could:

    a) Blacklist by serial number. For the meantime (i.e., ignoring the attempted Arduino revolution), most people who are using USB-serial adapters on purpose know enough to copy the serial number of their particular adapter into a blacklist. [The function compares the serial number to the blacklist and returns false if they match.]
    b) Blacklist by VID:PID and optionally whitelist by serial number. [The function compares the VID:PID to the blacklist and returns false if they match and the serial number does not match the whitelist.]
    c) Whitelist by serial number only.
    d) Potentially expose the hook as an extension point.

    2. On a slightly more hackish level but one that shouldn’t require code changes to gpsd itself, introduce udev rules that eliminate gpsd’s permissions to the serial device.

    Furthermore, have you considered the option of lazy activation of hotplugged devices? Since gpsd will back off if another process opens the tty first, this issue might be significantly mitigated if gpsd were to delay the active scan until a client opens a connection to the daemon—sort of introducing the opportunity for a race condition with the intended client of the device. New/upgraded clients might also be able to put gpsd into a passive mode if they know for some reason that it’s not necessary to scan for newly-connected devices at some particular point.

    Used for discovery only. I can explain why if you need me to, but I’m pressed for time right at this moment.

    It makes perfect sense, given that USB is basically only a serial bridge; I was just checking.

    1. >Given that hook, a user could:

      Given that hook, a user could do lots of things. But none of them is any more effective than deinstalling the hotplug rules and running gpsd by hand when you want it. So why bake in all that complexity?

      >Furthermore, have you considered the option of lazy activation of hotplugged devices?

      It already works this way.

  16. Serial #s are optional in the USB spec, and often vendors shave fractions of pennies per part by not using them (or by using the same one over an dover…)

  17. Serial #s are optional in the USB spec, and often vendors shave fractions of pennies per part by not using them (or by using the same one over an dover…)

    Hmm. I was aware they weren’t always present, but that latter is just evil.

  18. >but there has to be some way to tell GPSD not to touch that particular Vendor ID/Product ID.

    You’re making two wrong assumptions here.
    No, I’m not. The only assumption I’ve made is that you refuse to provide any blacklist mechanism whatsoever, due to your stubborn, arrogant insistence that your algorithm that Just Works 99% of the Time™ is good enough, and fuck the other 1% for wanting a way to make your software work and not have it bork their devices.

    I see your update:

    In particular it’s quite likely that your GPS and your serial-port adapter dongle will both be using a PL2303, so blacklisting by VID/PID will make both invisible.

    So fuck anyone who is using a PL2303 for a non-GPS and something else for a GPS. They can either do without their non-GPS device, or do without gpsd.

    You aren’t even trying here. If there is absolutely no way to distinguish between PL2303 devices that is guaranteed not to bork any of them, then you MVST provide a way to tell your goddamn program not to do it.

    You can complain all day about how it isn’t really your fault, but that of the PL2303 itself for designing a plug-n-pray system that doesn’t positively identify the devices behind it, but that’s bullshit and you know it. RS-232 devices themselves have no ID standard, which was a big driver behind the design of USB in the first place. You should therefore treat any PL2303 precisely as you’d treat any legacy RS-232 port, with one, very important difference:

    USB device-path assignments aren’t stable in the presence of hotplugging, enough said.

    So there are three responsible ways of dealing with the situation:
    1) Allow blacklisting by VID/PID as I suggested above
    2) Implicitly blacklist all USB-serial converters and allow whitelisting exceptions
    3) Allow explicit blacklisting and whitelisting exceptions.

    Saying “fuck the 1%” sounds… very Occupyish, if you ask me.

    1. >1) Allow blacklisting by VID/PID as I suggested above

      Effectively useless. In almost all cases, devices will present as oh shit yet another PL2303.

      >2) Implicitly blacklist all USB-serial converters and allow whitelisting exceptions

      If you whitelist by VID/PID, you’re back in everything-is-a-PL2303-hell. In the general case, you’re requiring random end-users to know details about their devices that they shouldn’t have to know, and to hand-configure them. Not acceptable.

      >3) Allow explicit blacklisting and whitelisting exceptions.

      See my remarks to Christopher Smith. If the devices presented enough information that explicit whitelisting/blacklisting would be useful, they would be presenting enough information that GPS could autoconfigure. But they don’t, so they don’t.

      Your thinking is lazy and muddy. Like most Unix hackers, you have a reflex twitch that the problem ought to be solvable with a config option, so you’re insisting on half-assed pseudo-solutions that will cost more complexity and trouble than they’re worth.

  19. Serial #s are optional in the USB spec, and often vendors shave fractions of pennies per part by not using them (or by using the same one over an dover…)

    So? Only if someone is using two devices with exactly the same VID/PID and neither one returns a serial number when queried would there be a problem with blacklisting by all three. No, it’s not 100%, but it gives people a chance to opt out of having their devices raped by gpsd.

    1. >but it gives people a chance to opt out of having their devices raped by gpsd.

      No rape ever occurs – you’re demonstrating that you still don’t understand the problem. GPSD doesn’t try to configure these devices, it just listens to them.

  20. “In the general case, you’re requiring random end-users to know details about their devices that they shouldn’t have to know, and to hand-configure them. Not acceptable.”

    How is that “in the general case”, when the suggestion seems to be that if the user doesn’t set up a config file it acts _exactly as it does now_?

    1. >How is that “in the general case”, when the suggestion seems to be that if the user doesn’t set up a config file it acts _exactly as it does now_?

      See my reply to Christopher Smith. Are you suggesting a config option that is simpler than just disabling the hotplug rules?

  21. Sure there are a lot of GPS systems out there that are PL2303 style broken but if you attack the problem the way it should be, part of the solution would be to get a GPS device class declared even though you know it is not a panacea.

    This way no matter what imperfect solution you adopt in the meantime, a portion of the exceptions your solution isn’t going to work for will be caught by the GPS device class. As time goes on, more and more GPS systems will carry the proper ID until you hit a tipping point where not having the ID costs sales because your system is considered broken (as well as being broken) by people who purchase GPS systems in large quantities. The old, broken kit will be out there for awhile (perhaps even many years) but it won’t be forever.

  22. “and we know device paths aren’t stable.” Do we? By “device paths” i assume you mean /dev/ttyUSB23 or whatever, but is there an identifier that can at least be narrowed down to a physical USB port (so you can blacklist the port that you always plug your non-GPS device into, or whitelist the port that you always plug your GPS device into)

    1. >is there an identifier that can at least be narrowed down to a physical USB port (so you can blacklist the port that you always plug your non-GPS device into, or whitelist the port that you always plug your GPS device into)

      What advantage would this have over:

      1) Disable startup on hotplug

      2) Start gpsd by hand with a list of ports know to have a GPS on them

  23. > But none of them is any more effective than deinstalling the hotplug rules and running gpsd by hand when you want it.

    You have set the worthy goal of always auto configure, but there are cases where autoconfiguration unavoidably fails. In such cases, the goal then is to fail gracefully.

    The problem then is that linux installs the hotplug rules by default, as it should since 99% of users would not know to install them. Trouble ensues, and 99% of users do not know to deinstall the hotplug rules. Hell, I am not the average user and I do not know how to deinstall the hotplug rules, nor what the consequences of deinstalling them is likely to be.

    If you are going to adhere to worthy goal of no config file, no user configuration, then need to apply some heuristics to detect that a device does not seem to be talking as a GPS would be expected to talk, pop up some UI that asks if autoconfiguration has stolen a non gps device, and ask if the user would prefer to go to manual. If the user says yes, advise the user on how to deinstall and reinstall the hotplug rules.

  24. 2) Start gpsd by hand with a list of ports know to have a GPS on them

    I haven’t been following closely enough to know you can pass gpsd a list of ports. I had assumed you could not because that would be a configuration option.

    1. >I haven’t been following closely enough to know you can pass gpsd a list of ports. I had assumed you could not because that would be a configuration option.

      Normally gpsd runs in zero-configuration without a port list, relying on the hotplug system to tell it which devices are live. But for testing and special purposes you can specify a list of ports to activate.

      The only other config option is -b to suppress attempts to autobaud and configure. I was dragged to that one kicking and screaming – only surrendered to it because there are some badly made Bluetooth GPSes that get bricked by incautious attempts to configure the baud rate,

  25. No rape ever occurs – you’re demonstrating that you still don’t understand the problem. GPSD doesn’t try to configure these devices, it just listens to them.

    No question about it. I don’t understand the problem. How can “just listening” be a problem? If all you’re doing is listening, how is that interfering with the operation of the device? Or is the mere act of listening causing the rightful owner of the data delivered by the device to be denied access?

    I thought we were talking about what you originally posted over a year ago, where probing these devices that turned out not to be GPSes caused problems.

  26. The solution I would use, when confronted with a device with a vendor ID used both by GPS’s and other USB->Serial devices, would to display a message to the user “A GPSD has detected a new device, but is unsure whether it is a GPS or not. Is this a GPS? y/n”.

    The difficulty, of course, would be determining *how* to display it to the user, who may or may not be running X, etc.

    @The Monster:

    I’d assume you’d get a “device or resource busy” message if you tried accessing a device that GPSD was listening to, but then again, “cat /dev/ttyUSB0” doesn’t seem to interfere with minicom, so I may be wrong on that.

  27. > Lots of people say this. Not one has come up with a “correction” that I consider more than a futile feel-good gesture, an assentially meaningless obeisance before the idol of configurability. Maybe you will be the first, but I’m not optimistic. I’ve been grappling with this problem for years.

    One solution: fork gpsd.

    1. >One solution: fork gpsd.

      Anybody has the right to do that, of course.

      But that doesn’t mean it would be a good idea. The GPSD code is saturated with hard-won domain knowledge. Our senior devs are wily and experienced at acquiring such knowledge. Anyone forking GPSD would take years to come up to that speed, and until they did their defect rate would be scandalously higher than ours.

  28. @Jon Brase, how would that work in embedded contexts like, for example, a GPS-enabled robot which may not have a user present during bootup? Remember, an “end-user mode” config switch is out of the question.

  29. > a GPS-enabled robot which may not have a user present during bootup?

    Suppose the robot has a GPS attached by USB, and an Arduino board attached by a USB – both of which have the identical device identifier: Other.

    I suppose that one then has the robots startup code manually run gpsd, and pray that no one ever plugs in the devices the wrong way around.

  30. The difficulty, of course, would be determining *how* to display it to the user, who may or may not be running X, etc.

    This is the general approach I was thinking of when I mentioned a passive mode—if all connected clients declare that they understand the new passive mode, gpsd sends a notification over the socket when a new device is detected before probing and allows the client to say whether it thinks the device should be considered a GPS.

  31. > But for testing and special purposes you can specify a list of ports to activate.
    > … [work around the problem by] deinstalling the hotplug rules and running gpsd by hand when you want it …

    OK, so there *is* a configuration workaround. It’s not one that the cognoscenti like, but there is a way to configure GPSD so as to work in the problematic environment.

    I think that now it’s just a SMOD (Simple Matter of Documentation) …

  32. SMOD (Simple Matter of Documentation)

    Aaaah. SMOD.

    Good documentation is never simple. Simple documentation is never good. And all too frequently documentation hits that point where it’s neither simple nor good.

    And regardless, all the documentation in the world is ignored anyway…

  33. I don’t get that it’s a problem. And if it is a problem, all the folk who it is a problem for can fork, and/or just write and maintain a patch for that functionality.

    ESR can simply continue on his merry way, and/or discuss with the forkers how to best maintain compatibility.

  34. “What advantage would this have over: 1) Disable startup on hotplug 2) Start gpsd by hand with a list of ports know to have a GPS on them”

    Because it doesn’t handle the case where you have hot-plug GPS devices and a static serial device which doesn’t handle GPSD well. You’ve got a whitelist-only option, and an auto-config only option. Adding an auto-config with a list of ports *not* to activate would be helpful in that case.

  35. Your thinking is lazy and muddy. Like most Unix hackers, you have a reflex twitch that the problem ought to be solvable with a config option, so you’re insisting on half-assed pseudo-solutions that will cost more complexity and trouble than they’re worth.

    This is going to go directly off topic.

    You sound like a central planner. You are assuming that you will always know better- I’m not sure how you can reject out of hand the idea that a particular user will have better information than you about that particular user’s special circumstances, and therefore a better idea of how gpsd might want to behave in their special case. You’re not willing to extend a knob out the back, give anyone an override…

    It looks to me like you’re extending the middle finger to the invisible hand.

    It seems to be that that Unix hacker reflex twitch is an acknowledgement that they don’t, and can’t, know/anticipate/deal with everything beforehand, themselves.

    1. >You sound like a central planner.

      That’s idiotic, and I suspect you’re just trolling. GPSD goes to great lengths to adapt itself correctly to the environment it finds itself in; you don’t have to tell it what device types or ports it will be using, nor serial baud rates or stop bits or any of that crap. Exactly the opposite of the “central planner” approach which would insist that the environment must be predesigned to conform or you’re screwed.

      What I reject – vociferously and with extreme prejudice – is the lazy, stupid thinking that reaches for configuration switches rather than doing the hard work required to get autoconfiguration right.

  36. @Greg
    > You’re not willing to extend a knob out the back, give anyone an override…

    No. Your assumption is that the problem is with GPSD, when it is far more correct to say the problem is with both A.) the awful tragedy known as USB, and B.) modern Linux distros’ hotplug implementations.

    Three choices:
    1.) Extend GPSD, adding complexity in a way contrary to its stated goals
    2.) Fix USB and all the shoddy manufacturers of USB devices. Heh.
    3.) Make hotplug not suck / configure as needed.

    #1 would, by the metrics of the project, cause a decrease in software quality.
    Not a chance in hell of #2.
    #3 configuration is possible by the small number of end-users this affects, and the more projects like GPSD hold firm the more impetus there is to fix the ugliness on a wider scale. There is no need for an override in GPSD when you can accomplish the same thing at the system level.

    The modern Linux morass has come about in no small part due to people advocating #1 for solutions. See also GNU.

  37. What I reject – vociferously and with extreme prejudice – is the lazy, stupid thinking that reaches for configuration switches rather than doing the hard work required to get autoconfiguration right.

    A laudable position to take, but it makes an assumption that may not be valid: that it is possible for autoconfiguration to work reliably, first time, every time. How would you propose to handle the cases where it doesn’t work and can’t be made to work?

    1. >How would you propose to handle the cases where [autoconfiguration] doesn’t work and can’t be made to work?

      With a configuration switch, of course.

      The problem isn’t that such switches are inherently evil, it’s with the bad mental habit that reaches for them too soon. Better to write code that cannot do the wrong thing than a switch to tell it not to.

  38. > Aaaah. SMOD.

    I know. I used that phrase in (conscious) reference to SMOP, sense 2: http://catb.org/jargon/html/S/SMOP.html

    Nonetheless, one solution to this problem is for *someone* to describe how to “deinstall the hotplug rules and configure gpsd manually”. Given that Eric doesn’t seem to want to abandon his design goal of “no configuration switches”, it seems like the *only* solution he’s likely to accept.

    > And regardless, all the documentation in the world is ignored anyway…

    Not if the Benevolent Dictator points the complaining user to Chapter and Verse, saying RTFM …

  39. >You sound like a central planner.

    That’s idiotic, and I suspect you’re just trolling.

    He’s not the only one getting that vibe from your attitude. For a person who self-identifies as anarchist/libertarian, you certainly must be aware of the Knowledge Problem. But when it comes to GPSD and auto-configuration, it’s as if you are a caricature of the Soviet Five Year Plan authors or a government official out of Atlas Shrugged.

    You have the undiluted hubris to think that you and your team of programmers can anticpate every possible situation that might arise, and unfailingly Do The Right Thing™ without any configuration options at all for the stupid users to mess up. But the universe doesn’t work that way. There is always local knowledge unavailable to “experts” who try to design the right ruleset.

    Yes, your rules can be right the overwhelming majority of the time. But there will always be exceptions. The nature of the problem is such that certain facts that are knowable to your users cannot ever be knowable to gpsd without some mechanism for passing that knowledge from the brains of the users. You can all it a “config file”, a “command-line option”, an “environment variable”, or ${foo}, but so long as your attitude is that you don’t need no steenking configs, you’ll never be able to use that knowledge.

    If Apple expressed precisely the same attitude about iPhones as you’ve expressed about gpsd, you’d rightly call them out for it. But for some reason, you’re unable to see it in the mirror.

    1. >There is always local knowledge unavailable to “experts” who try to design the right ruleset.

      Not in this case. The devices don’t supply that knowledge. If they did, I could autoconfigure with it

  40. “Not in this case. The devices don’t supply that knowledge. If they did, I could autoconfigure with it”

    Er, his entire point is that there may be knowledge unknowable to you [i.e. not supplied by the devices] that _is_ known _to the users_.

    1. >Er, his entire point is that there may be knowledge unknowable to you [i.e. not supplied by the devices] that _is_ known _to the users_.

      He’s wrong. In the absence of fixed mappings between physical machine ports and software device paths, users cannot have such knowledge. The path to a GPS today could host a non-GPS tomorrow, or vice-versa. The VID/PID pair behind which there is a GPS now could have a non-GPS behind it next time.

  41. TMLutas said: Sure there are a lot of GPS systems out there that are PL2303 style broken but if you attack the problem the way it should be, part of the solution would be to get a GPS device class declared even though you know it is not a panacea.

    That would help a lot (and, Eric, that actually sounds like something you should Get Someone To Do; pester USB-IF to add a damned GPS profile!) for the future, eventually, probably.

    But it won’t do anything for the next few years, or ever help the existing pl-2303 (or equivalent, but mostly pl-2303) hell we have now.

    So, I can see why it’s not priority one, so to speak – it’d take probably 3-5 years to get included, and there’d be literally millions (tens? hundreds?) of devices in use and in the pipeline that didn’t use the profile.

    (I’m also with Eric vs. the others – I don’t have ESR’s knowlege of the deep levels of USB-fu in Linux, but I do recall from the very earliest days that /dev entries are not reliable like that. The entire architecture is kind of a mess – and not entirely due to Linux, but to USB as well.

    If, for instance, we lived in a world where ever USB device had, say, the optional serial number, and where every GPS or GPS-maker had a serial number or set of serial numbers that could be decoded to get “this is a GPS”, that would be grand. But we don’t live in that world.))

  42. He’s wrong. In the absence of fixed mappings between physical machine ports and software device paths, users cannot have such knowledge. The path to a GPS today could host a non-GPS tomorrow, or vice-versa. The VID/PID pair behind which there is a GPS now could have a non-GPS behind it next time.

    Somehow, somewhere, sometime, somebody could plug that VID/PID into some computer and it might have a GPS, or it might not. That is the extent of your knowlege, Mr. Central Planner.

    But the individual user knows what he’s plugging into his computer and when he does it. He may know that he has a non-GPS device that uses a particular ID, and despite the fact that some GPSes use that ID, he is not using any of them. These are things he knows, which you can’t know a priori, which you’ve stated as a matter of principle you don’t want him telling you. You just keep reiterating that your expert, centralized decision-making is superior to his local knowledge.

    At the risk of repeating myself, on any other subject, you’d be ripping the authoritarian bastards with this attitude to shreds. And I’d be enjoying it.

    1. >You just keep reiterating that your expert, centralized decision-making is superior to his local knowledge.

      Nonsense. I’m not making any decisions about his configuration; I don’t know it. The adaptive algorithms I put in GPSD are ‘deciding’ based on the local knowledge they can gather. This difference disposes of your idiotic “central planning” drivel.

      I will cheerfully accept suggestions for improvements to those algorithms, or ways they can gather more local knowledge. I will not accept demands that I add configuration switches that will only add complexity without solving the actual problem.

  43. >3) Allow explicit blacklisting and whitelisting exceptions.

    See my remarks to Christopher Smith. If the devices presented enough information that explicit whitelisting/blacklisting would be useful, they would be presenting enough information that GPS could autoconfigure. But they don’t, so they don’t.

    Am I missing something obvious?

    In the general case you are correct. In particular cases you may not be- and only the individual local user could know the difference, because only he knows his own inventory.

    Though in fairness (this is going to be Linux-centric because only on Linux have I even gotten under the hood with usb devices) an individual who knows his own inventory could work around weaknesses in gpsd’s autoconfiguration by writing his own udev rules. Oh and it is not necessarily true that USB device assignments be unstable in the presence of hotplugging, because the ability to write custom udev rules exists. My usb backup hd always has a fixed device name…

    1. >In particular cases you may not be- and only the individual local user could know the difference, because only he knows his own inventory.

      What problem case do you think you’re actually solving?

      We know that gpsd will never send config strings to a USB device it hasn’t identified. Worst case is it will open the device and read some data. We know that gpsd won’t even read from a device that is already opened by another process – it checks. We also know (well, you may not) that gpsd uses TIOCEXCL to assert exclusion when it successfully opens a device.

      So the only situation is which there is even a potential problem is when a non-GPS is attached, the hotplug notification puts it in gpsd’s device pool, and then some GPSD client ships gpsd a watch request (triggering gpsd device activations) before the application that wants the non-GPS device opens it. Because of the TIOCEXCL, the worst case for that application is that its device open fails, not scrambled data or anything. And you have to hit a tiny window for that; gpsd only has to sniff a device for less than a second to identify it as not-a-GPS and throw it back.

      All of the suggestions I’ve heard for configuration options to address this non-problem are fatally flawed. They cannot be otherwise because the information required to implement a useful config option is not present, VID/PID pairs don’t identify devices, device serial numbers aren’t reliably present or unique, device paths are unstable.

      I repeat: What problem case do you think you’re actually solving? Out of fear that GPSD might once in a blue moon cause an open of a class 00/FF device to fail you want me to implement config switches that won’t work?

      The people who have been going on about “rape” of devices and how sinful it is to touch any device that’s not a GPS are blathering, and all the crap about configuration options is just an unhelpful Unix cultural reflex that’s short-circuiting their thinking. (This is the author of The Art of Unix Programming speaking ex cathedra :-).)

  44. What I reject – vociferously and with extreme prejudice – is the lazy, stupid thinking that reaches for configuration switches rather than doing the hard work required to get autoconfiguration right.

    I’m coming late to this, but I’d just like to say that Eric is absolutely right.

    What a lot of programmers do not realise (and it’s a disease as common among iOS developers as Unix hackers) is that every configuration option comes at a price. It’s a price of complexity to the user and to the programmer. Every additional configuration option adds an extra test case that the programmer needs to take into account and an extra failure case that the user could run into. In fact it’s worse than that, because every additional switch actually *doubles* the number of possible configurations. For every configuration that existed previously, there are now two in its place; one with the switch on and one with it off.

    1. >(and it’s a disease as common among iOS developers as Unix hackers)

      Ironically, I decided to push GPSD towards zero-configuration after thinking for a long time about what the world would be like if MacOS as it then existed lived up to its propaganda.

  45. The adaptive algorithms I put in GPSD are ‘deciding’ based on the local knowledge they can gather.

    After meta-deciding you don’t want the guy who uses the damn thing to give you any local knowledge. You refuse to gather that sort of knowledge.

    I will not accept demands that I add configuration switches that will only add complexity without solving the actual problem.

    The problem is not solvable. There is no good answer.

    One of the things that distinguishes the Left from the rest of us is that they believe in solutions; while the rest of us recognize that there are often no solutions, only tradeoffs. Again, on any other damned thing, you’d see it.

    And I’m not “demanding” a goddamn thing. I’m just pointing out your blind spot, killing your Buddha. You can keep insisting that your superior knowledge justifies not having any configuration switches, and I’ll keep saying your attitude* has a lot in common with every petty tyrant who knows what’s best for me.

    *To be fair, you have three very important distinctions that separate you from those tyrants:
    1)Your code is under a license that allows HPA or anyone else to add the config switches you stubbornly refuse to admit anyone has a legitimate need for.
    2) You’re not proposing a law to prevent anyone from using config switches you don’t like.
    3) You tolerate dissenting opinions like this on your blog.
    So you have that much going for you.

  46. The problem is not solvable. There is no good answer.

    Well, then, why change anything?

    We already have the approach of 1) Disable startup on hotplug, and 2) Start gpsd by hand with a list of ports known to have a GPS on them. This already handles 100% of situations where you don’t want to use gpsd autoconfig and know enough about your GPS to identify it specifically to gpsd.

    It is very slightly more work for the tiny subset of cases where a person has a non-PL2303 GPS they’d like to autoconfigure and a PL2303 non-GPS they want GPSD to leave alone than a config option that would disable probing PL2303s. But it also ensures avoidance of spurious bug reports where the user loses his GPS, buys a new (PL2303-using) GPS, and can’t figure out why auto-config isn’t working, because of a long-forgotten config switch used to avoid collisions with an Arudino board he hasn’t touched in the last year anyway.

  47. “I repeat: What problem case do you think you’re actually solving?”

    When I “blathered” about “raping” devices, it was because you hadn’t explained any of that yet. All you were doing was poo-pooing HPA’s concerns, with no link to help establish context. Since the last time this subject came up, there was discussion of actually bricking devices by probing them, I was responding to that context.

    Now that you’ve said that you believe the worst-case scenario is that an application that wants to open the device fails on its first try and has to retry in a second or two, I’d say that how big of a deal that is depends a hell of a lot on what that device/app combo is. Just because you can’t imagine why it’s a big deal doesn’t mean it isn’t to someone out there who has the local knowledge you don’t have.

    Lacking that link to place HPA’s comment in context, I don’t know if I can come up with a realistic scenario you’ll deem worthy of addressing. Is his concern that the device will deliver some critical data to GPSD instead of to his app? Is it that the app might not be able to open the device and therefore fail to receive some later data?

    I don’t look at G+ much since they decided to suspend my account over the obvious nym, but if someone can point me to the original discussion, I’ll try to see if HPA was still addressing the same old concern as I was, or has some other particular nightmare in mind.

  48. I’m sure porting GPSD to VB.Net will fix everything. Leverage the stability of the modern Windows HAL.

  49. I think that this whole thing is one of those things that you’ll just have to live with, as it will go away with time. GPS devices are mass-market things, and as such, their manufacturers have every incentive to eliminate that pesky serial-usb chip, and have their micro drive the usb port directly. By then, there will be an incentive for a GPS device class, as well.

    1. >By then, there will be an incentive for a GPS device class, as well.

      But it will matter less if there isn’t one, because your hypothetical single-chip USB GPS mouse will have its own VID/PID pair that will identify it.

      I’ve been a little puzzled why the device you describe doesn’t already exist. The production volume to justify it seems to be there.

  50. In a recent Google+ comment, H. Peter Anvin grumped about GPSD […]

    esr, could you provide a link?

  51. > In the absence of fixed mappings between physical machine ports and software device paths, users cannot have such knowledge.

    So, the mappings between physical machine ports and software device paths (though not fixed) can’t be examined at runtime? What’s all this stuff in /proc and /sys? (I know this would be Linux specific, but I wonder if other OSes don’t provide a similar mechanism)

    I don’t have any USB-serial devices to test with, so maybe the information is not exposed. I do know that the hierarchy of hubs and physical ports is itself exposed, though.

    1. >So, the mappings between physical machine ports and software device paths (though not fixed) can’t be examined at runtime?

      Of course they can be. The problem is that with everything so mutable, there’s no way to identify a single device across multiple hotplug events so it can be targeted for blacklist or whitelist. There’s no equivalent of disk UUIDs.

  52. > I’ve been a little puzzled why the device you describe doesn’t already exist. The production volume to justify it seems to be there.

    Does the device that you are working on for the bufferbloat stuff have this property? If not, why not?

    1. >Does the device that you are working on for the bufferbloat stuff have this property? If not, why not?

      No. It’s a slight mod of a bog-standard two-chip design. Nobody’s designed a single-chip USB GPS yet.

    1. >GPSD used to have a perfectly fine configuration file, Eric, and /etc/init.d/gpsd started gpsd like this:
      gpsd `cat /etc/gpsd.config`

      Perfectly good except for the minor detail that requiring the user to specify a path, a device type, and a set of serial parameters was utterly unnecessary. So, yes, that invocation performed a fine execution of a useless job.

  53. Oh, but, y’know, there *is* a way to tell what USB socket a device has been plugged into. You *could* blacklist certain sockets, or hubs, or {sockets on hubs, or hubs on sockets on hubs}*.

    1. >Oh, but, y’know, there *is* a way to tell what USB socket a device has been plugged into. You *could* blacklist certain sockets, or hubs, or {sockets on hubs, or hubs on sockets on hubs}*.

      This doesn’t help. It’s too hard to predict what socket will be bound to a particular port in advance. And you have to be able to do that, otherwise you don’t know what your blacklist option will end up blocking.

  54. > Of course they can be. The problem is that with everything so mutable, there’s no way to identify a single device across multiple hotplug events so it can be targeted for blacklist or whitelist.

    But you can target a port [rather than a device] then? This seems to contradict “In the absence of fixed mappings between physical machine ports and software device paths, users cannot have such knowledge.”

    So, the user knows what port they intend to plug a device – either the GPS device, or the other problematic serial device – into (this is the local knowledge). The software can know what port a device was just plugged into. What’s the problem?

  55. >I repeat: What problem case do you think you’re actually solving? Out of fear that GPSD might once in a blue moon cause an open of a class 00/FF device to fail you want me to implement config switches that won’t work?

    I think people are assuming that HPA was complaining about an actual problem: I.e, that GPSD not only might but actually *does* cause an open of a particular class 00/FF device to fail, and that you are refusing to implement a means of working around that failure (whether that’s a config switch, a query dialog, a front end program that the user can use to tell gpsd “I’m about to plug a device into USB port three, and it is/n’t a GPS”, or something entirely different).

    If HPA was complaining about an actual instance of GPSD interfering with non-GPS devices, then I’m going to agree with everybody else that you need to implement some way of dealing with that failure.

    If HPA was just complaining about potential problems that haven’t shown up yet, then I agree with you.

    1. >If HPA was just complaining about potential problems that haven’t shown up yet, then I agree with you.

      It does not appear from any of HPA’s comments that he tripped over an actual bug.

      In fact, since 2005 I have had a maximum of three (3) bug reports that might (might!) have been attributable to such a collision. And none since I installed the fusercount check that prevents GPSD from opening a device another application has opened.

  56. … and yet as several people have pointed out, it *is* necessary to not open up some serial ports some time. For example, we have a device that spits out NMEA data, and a GPS receiver. Is GPSD going to reliably leave the NMEA device alone?

    1. >it *is* necessary to not open up some serial ports some time. For example, we have a device that spits out NMEA data, and a GPS receiver. Is GPSD going to reliably leave the NMEA device alone?

      No, not if it’s presenting as one of the USB adapters GPSD thinks mean a likely GPS behind it.

      If you’re doing stuff this odd, you disable the udev rules. Period.

  57. And I was also trying to point out the hack that gpsd *never* had a configuration file. It had command-line switches, and you could put them into a file if it made you happy.

  58. This strikes me as a really stupid question, but would exposing an interface to GPSD at a scripting/library level help?

    I.e. if native gpsd does (in pseudo-python) :-
    Devices = Discovery()
    GPSD(devices)

    Someone could replace /usr/sbin/gpsd with :-
    Devices = Discovery()
    GPSD(removePL203(devices))

    And thus solve their own issue without forking gpsd.

    1. >This strikes me as a really stupid question, but would exposing an interface to GPSD at a scripting/library level help?

      There’s already partitioning something like that between gpsd itself and the udev rules and scripts. To understand this, you need to know what the consequences of a hotplug even on an eligible device are.

      1. The Linux hotplug system detects that a USB device has plugged in.

      2. The device VID/PID is run through the udev rules that GPSD normally installs. If it doesn’t match, we’re done.

      3. Otherwise, the udev rules call a shellscript, gpsd.wrapper sets some environment variables and calls gpsdclient with the activated device path as an argument.

      4. gpsdclient starts gpsd if necessary, then stuffs a notification including that device path down gpsd’s control socket.

      5. gpsd adds the device to the pool of sensors. It is only opened immediately if a client has a watch request active when the device is added; otherwise, open is delayed until some client requests a watch.

      The place to intervene would be in the wrapper script. After that point knowledge of the VID/PID is discarded.

  59. What you need is the equivalent of ungetc(3) … find the device, mistake it for a GPS, read some data from it, realize it’s not a GPS, push it all back, and back off.

    *shrug*

  60. Is there any way, once GPSD realizes that the USB device is not a GPS, to give the hotplug subsystem a ‘kick’ to force a device reinitialization that can then be ignored completely by GPSD?

  61. > In particular it’s quite likely that your GPS and your serial-port adapter dongle will both be using a PL2303, so blacklisting by VID/PID will make both invisible.

    If both invisible, then the user has to manually launch GPSD when plugging in his GPS, an minor inconvenience for the minority of users who have different devices both with the same VID/PID.

    Of course, no two different devices should ever have the same VID/PID, and if they do it is a manufacturer bug, which bug is itself caused by the committee that allocates VID/PIDs going evil and insane, creating an artificial shortage of VID/PIDs

    But, given that the bug exists, the workaround is to blacklist hotplugging of devices whose VID/PID collides on a particular machine, and when such a device is hotplugged, the user has to manually launch the software appropriate for that device.

    1. >Of course, no two different devices should ever have the same VID/PID, and if they do it is a manufacturer bug, which bug is itself caused by the committee that allocates VID/PIDs going evil and insane, creating an artificial shortage of VID/PIDs

      This is wrong. VID/PID pairs are supposed to be unique to device types not devices. The mechanism for allocating them is doing its job; the problem is with the GPS manufacturers, who are not requesting VID/PID pairs for their GPS products and instead leaving the VID/PID pair for the serial adaptor in place.

      In some ways life if they did the “right” thing might be worse, though. We’d go from a dozen udev rules matching VID/PID pairs for USB-to-serial adapters to hundreds, with a new one being added for every supported GPS. It wouldn’t scale well.

  62. If two different devices on the same computer, requiring different software, have the same VID/PID, hotplugging just is not going to work, so there is simply no question of supporting hotplugging. You have to make hotplugging fail as gracefully as possible.

    If someone wants to support two devices with the same VID/PID on the same computer, then he just cannot have the right software come up automatically when they are plugged in. He has to manually run the right software on plugin.

  63. Isn’t GPSD open source? If you guys really think it would be better with a config file, why not fork it and add the config file. Then let the market decide which version they prefer. Seems to me that would be the best way to tell if a config file would actually be worthwhile, rather than arguing about it on a message board.

    I do think a lot of the problem would have been avoided if the word “bogarts” had not been used in the title. It is uncommon, and I would wager that a lot of people interpreted it as “ruins” or “destroys”. A better word might have been “hogs”,”monopolizes”, or “intercepts”.

  64. Nope. I didn’t get the specific reference. I just thought it was generic drug slang from an earlier decade.

    Either way, I don’t think the clever reference was worth the confusion it obviously caused your readers.

  65. I looked it up to be sure I wasn’t missing anything:

    Definition of BOGART
    transitive verb
    1
    : bully 2
    2
    : to use or consume without sharing

    I’d only heard the second definition before. Of course, there are some different connotations for what it means to “consume” a device….

  66. @James A. Donald “Of course, no two different devices should ever have the same VID/PID, and if they do it is a manufacturer bug, which bug is itself caused by the committee that allocates VID/PIDs going evil and insane, creating an artificial shortage of VID/PIDs”

    No, the bug is clearly caused by manufacturers cheaply making devices that are really two different devices jammed together in a single package [a serial GPS device and a USB-to-Serial converter].

  67. > the probllem is with the GPS manufacturers, who are not requesting VID/PID pairs for their GPS products and instead lreaving the VID/PID pair for the serial adaptor in place.

    Maybe they are not requesting because it takes a great deal of money, time, and effort, and is apt to get one sued.

    1. >Maybe they are not requesting because it takes a great deal of money, time, and effort, and is apt to get one sued.

      The former is plausible, but nothing about the process suggests lawsuit risks to me.

  68. > nothing about the process suggests lawsuit risks to me.

    http://www.voti.nl/docs/usb-pid.html tells us that he used to sell PID numbers, and was threatened with a lawsuit. He tells us that two chip manufacturers make PID numbers readily available to their customers, but that he only knows of two that do this, so presumably if you buy a USB chip for your GPS chip from any other manufacturer, you are hosed. This is a situation of lawsuits and artificial shortage.

    Plus, it is simply a law of human nature that any large long established committee will be evil and insane, and will wind up obstructing whatever it was originally created to facilitate. There is no Parkinson’s law covering large committees, so I hereby proclaim this as Jim’s law of large committees.

  69. After due consideration, I’ve decided that auto-probing of serial ports is a BAD BAD idea, regardless of whether they’re serial chips, USB /dev/ttyUSB, or /dev/ttyACM. It’s reasonable to do it once, and write out a configuration file. But it’s not reasonable to do it every time at start-up.

    Or, in other words, NetworkManager and modem-manager must die.

  70. You should see log messages from gpsd indicating that the control socket has received a command to add the device, and then data from the device. When you unplug and replug the device, gpsd should emit messages about the device closes and opens.

  71. FWIW: 47, grew up in New England, did not hang out with the druggies; got the bogart reference immediately.

    Russell: so how does networkmanager locate my modem/ethernet PCMCIA card?

  72. “Of course they can be. The problem is that with everything so mutable, there’s no way to identify a single device across multiple hotplug events so it can be targeted for blacklist or whitelist. There’s no equivalent of disk UUIDs.”

    In some ways, the most interesting part of this thread has not been the technical discussion, but the social one. Tremendous resistance has been expressed here to the idea than given the constraints, there is no solution that meets the engineering-mindset’s need to solve the problem.

    There must be some way to set up a config file to do this, right? You just tell it to ignore the device that…you ignore it if….wait, let me think…

    But no — there are some issues that live in a problem space so tightly constrained that there are no solutions without redefining it (which here, means changing the VID/PID ID’s at the manufacturer).

  73. I understand you reasoning re auto-config and love gpsd for what it does and how it does this. Until now, when I have fallen in the same pit.

    How about not using a gpsd-config file or switch, but someone elses? Like udev-rules. “If there is a udev rule matching the newly discovered port – don’t touch it, the user probably has other ideas about it”. By ‘don`t touch it’ I mean don’t open for read, don’t make a symlink in /dev etc.

    Example at hand:
    The Kenwood TH-D72A/E series of handheld amateur radio transceivers. They identify as yet another UART bridge with vid:pid 10c4:ea60. The good thing about this device is that it has a serial number. This can be used in a udev rule to identify this individual device. My idea is simply that when a udev rule like this exists, leave it alone.

    Funny enough, the TH-D72 radio has a GPS receiver built in, and the USB port can act as a NMEA device, so it could be used as a source for gpsd. But in many cases the user has the USB port configured differently, namely to output APRS data for amateur radio purposes.

    1. >My idea is simply that when a udev rule like this exists, leave it alone.

      This sounds interesting, but I don’t know how to implement it. udev is a moving target; lat time I checked, rule assignment wasn’t dynamic enough to do what you’re suggesting; it might be now, though. Do you have a concrete implementation strategy in mind?

  74. > Do you have a concrete implementation strategy in mind?

    After reading more about USB and udev I understand a little bit better what nightmare that all is. But I also understand that it is hard to do otherwise (given the USB specs).

    Here is how I would do it:

    a.) Have the user provide a udev-rule which is triggered _before_ gpsd’s rule (i.e. it has a lower number).

    b.) Have the users udev rule set an environment variable like
    ‘GPSD_VETO=devicename[,devicename]’
    The debian wiki says that you can use ENV vars from one rule in a later rule, didn’t test it though.

    c.) Have gpsd check the GPSD_VETO var, which can be a list(!) of USB device names, e.g. ‘/dev/bus/usb/006/014’, separated by comma. The device name is the substitution %N of udev rules. There are other substitions available, dunno if this is convenient or not, see man udev.

    Any device listed in this ENV var is recognized as otherwise claimed and is not handled by gpsd.

  75. An afterthought in case you don’t want to handle (another?) ENV var.

    Let the users udev rule set a symlink to that device.
    Let gpsd check if this device already has a symlink, if yes leave alone.

    I find this approach somewhat more opaque, more like black magic… I would prefer a clearly named ENV var.

Leave a comment

Your email address will not be published. Required fields are marked *