Zack's Kernel News

New GNSS GPS Subsystem

There was recently a scuffle over adding a new subsystem that ended with an odd resolution. Johan Hovold posted some code to add a Global Navigation Satellite System (GNSS) subsystem to the Linux kernel to support GPS devices. One of the motivations for this was the wide array of input/output systems used by these devices. Some relied on UART for communications over a serial port; others used USB ports. There were a variety of other interfaces, too. Johan wanted to create an abstraction layer, so user code could interact with GPS devices regardless of their particular hardware interface requirements. His idea was to create a new /dev/gnss0 file in user space, which could be used to query and control any GPS device attached to the running system.

To get things started, Johan had also implemented drivers for the SiRFstar and u-blox GNSS chips.

Pavel Machek could not go along with this. He pointed out that there was not, in fact, any GNSS-specific code in Johan's patches and that the code was simply a serial-device power management subsystem that couldn't handle a variety of GPS devices. He said, "This will never handle devices like Nokia N900, where GPS is connected over Netlink," an already-existing socket interface within the Linux kernel.

Johan replied that the whole point of the abstraction layer was to let user space detect GPS devices without having to come up with its own hacky code to probe for them. That was what made it GNSS-specific. The latest version of his patch, he said, also exported a GNSS receiver type and also implemented the GNSS-specific drivers for SiRFstar and u-blox. Finally, he pointed out that the code was not serial device specific, because it worked on other interfaces too.

Pavel still disagreed. He said the exact same features Johan had implemented could be applied to AT modems (i.e., modems using the Hayes AT command set). Pavel pointed out that AT commands also went across a variety of different interfaces.

Pavel said there were plenty of GPS devices, such as the Nokia N900, that wouldn't work with Johan's code. A proper GNSS subsystem would need to support all GPS devices. He said, "I believe we really want to use your code for AT commands, too. And we really should keep GNSS/GPS names for future layer that actually provides single interface for userland."

Johan defended his patch, saying, "It's a matter of finding the right abstraction level. A userspace location service will now have easy access to the class of devices it cares about, without having to go through a list of other random devices which happen to use a similar underlying interface."

He added that if part of his code turned out to be reusable for a yet-deeper subsystem in the future, he'd be fine with that. But for the moment, he said, his code met the needs of the situation.

Johan also added that some vendors used their own priority binary-only protocols for GPS devices, and there it wouldn't be feasible to reverse engineer and support them all. He said that for a lot of those devices, it would be fine to let them remain a userspace problem. There was no need to put support for all of them into the kernel itself. Only the ones that were amenable.

Pavel reiterated his complaint that Johan's code was not a real GNSS subsystem. He said Johan should pick a name that more accurately described what his code did, so that a real GNSS subsystem wouldn't come along and find its proper name already taken.

But Johan replied, "It's about grouping related devices together, devices which share some common functionality. In this case, providing location data from some satellite system. I really don't understand how you can find having a class type named gnss for this to be controversial in any way. [...] I find naming a subsystem for GNSS receivers gnss to be very reasonable."

He pointed out that the patch solved a real-world need, and he remarked that if Pavel found a better GNSS subsystem in the future, it could always be added into the kernel at that time.

Johan also looked at the specs for the Nokia N900 that Pavel had mentioned and said:

The N900 service you link to above, parses phone data, does some floating point calculations, and generates NMEA sentences, which it feeds to a pseudo terminal whose slave side is opened by gpsd.

That NMEA data could just as easily be fed through a different kernel subsystem, namely gnss instead of tty, where it could be accessed through a common interface (for now, a raw gnss interface, with some associated metadata). (And from what I can tell, ugnss would also allow you to get rid of some hacks related to finding out when the GNSS is opened and needs to be powered on.)

So the ugnss interface looks like it will work for N900 just as it will for other phones.

Pavel disagreed with Johan's idea of grouping devices together by functionality. He said, "We normally group devices by interface, not by functionality." He added that if the wrong name was chosen now, it would be impossible to fix later.

Johan replied:

I started off with separating the gnss device itself from the raw interface (cf. hid) to allow for something like that, but the more I looked into this, the more it seems I was just over-engineering for something that would never be realized.

Take a look at some of the papers on the gpsd site about GNSS protocols and the problem of finding a common representation for all the various devices out there. gpsd itself has already gone through three revisions of its internal representation over the past decades. This does not seem like an exercise we want to repeat in the kernel with its rules about backwards compatibility, etc.

So at least for the time being, I'm convinced that a raw gnss interface is the right one.

At this point, Greg Kroah-Hartman undercut the entire debate with one sweeping gesture. He accepted the patch, saying, "This all looks great. Thanks for doing this work and adding a new subsystem for something that has been asked for for many years. All now merged in my tree, nice job!"

Pavel replied that the debate wasn't finished yet. He reiterated his basic points, saying "there's nothing GNSS specific in those patches. It does not know about the format of the data passed around. (Best you can claim that somehow data flow characteristics are unique to GNSS.) And this takes namespace needed for real GNSS subsystem. Please don't do it."

But Johan just replied, "This is the real GNSS subsystem. Get over it." And Greg said the debate looked done to him. He said, "there was only a single set of patches, with no other working patches submitted from anyone else. If this turns out to be a 'bad' api, then we can deal with it then, but for now let's try this out."

And that was that.

It's unusual for one big-time kernel person (Greg) to overrule another big-time kernel person (Pavel) so abruptly. At the same time, Johan's code did address a current need, and no alternatives rose up to present themselves. One aspect of Linux development philosophy seems to be accepting a less-than-perfect solution, partly because it is a solution, and partly because it forces the naysayers to put up or shut up. Linus Torvalds tried this with BitKeeper years ago. While it didn't result in the naysayers producing a viable alternative, it was itself a good temporary fix and eventually did lead to the creation of the Git revision control system and the changing of the world for the better.

New LoRaWAN Subsystem

Jian-Hong Pan wanted to know if there was support among kernel developers for a new LoRaWAN subsystem. He explained, "A Low-Power Wide-Area Network (LPWAN) is a type of wireless telecommunication wide area network designed to allow long range communications at a low bit rate among things (connected objects), such as sensors operated on a battery. It can be used widely in IoT area. LoRaWAN, which is one kind of implementation of LPWAN, is a medium access control (MAC) layer protocol for managing communication between LPWAN gateways and end-node devices."

He asked, "Could or should we add the definitions into corresponding kernel header files now, if LoRaWAN will be accepted as a subsystem in Linux?" And he posted a link to his Git repository that held his work so far: https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN.

Jirí Pírko pointed out that a repository wouldn't be enough – Jian-Hong would need to send a patch against the kernel tree itself.

And Marcel Holtmann remarked, "when you submit your LoRaWAN subsystem to NetDev for review, include a patch that adds these new address family definitions. Just pick the next one available. There will be no pre-allocation of numbers until your work has been accepted upstream. Meaning, that the number might change if other address families get merged before yours. So you have to keep updating. glibc will eventually follow the number assigned by the kernel."

Andreas Färber also replied, saying he'd been working on a similar project for the past year. He gave a link to his proof-of-concept code: https://github.com/afaerber/lora-modules.

Andreas asked if Jian-Hong thought their two projects were independent or in conflict with each other.

Jian-Hong replied, "Wow! Great! I get new friends:)"

He said it looked like their projects had the same idea and proceeded to examine possible further areas of overlap and/or conflict, but the discussion ended there, probably because Andreas and Jian-Hong took it to private email.

It's not uncommon for two developers to suddenly discover that they've been working on the same project. It seems like a basic part of the scratch-an-itch philosophy is that more than one person might feel the same itch at the same time. Sometimes a developer might work in private for a long time, reluctant to reveal their project until they felt it could be defended. Sometimes two projects might represent such an opposing worldview that they are truly mutually exclusive: two different schedulers, for example, or two different out-of-memory killers, or two different load balancers. But two different implementations of the same known protocol are much more likely to mesh well and end up enhancing each other rather than forming a new point of conflict.

My guess is that Andreas and Jian-Hong will merge their projects, form a team, and get their code into the kernel twice as fast as they would have before.

Tracking Compiler Dependencies at Config Time

Masahiro Yamada recently posted some documentation for the new elements of the Kconfig macro language requested by Linus Torvalds in February. The idea was that the kernel build process had been accruing a vast number of hacky tests for various compiler features, covering kernel options that depended on whichever compiler the user had installed. There was no way, with the current setup, to reveal those details during the configuration phase.

Linus wanted the Kconfig macro language to include features to specify dependencies on specific compiler versions or particular compiler features, so that all of those dependencies could be resolved at config time rather than compile time. This would clean up the makefiles and make everything a lot more sane. It would also make it easier for kernel feature developers to add features without needing to know everything about compiler versions.

Masahiro documented the resulting language additions. It included a bunch of definitions for variables and dependencies, similar to those offered by make. In fact, make was specifically used as the model for the Kconfig enhancements.

Kees Cook liked the docs, although he preferred using a markup language on the documentation instead of just plain text, but he approved the patch. Randy Dunlap also had a few minor suggestions and approved the patch.

There was no particular discussion – Linus' favorite features tend to be implemented quickly and go into the tree with very few bumps.