Sometimes kernel developers find themselves competing with each other to get
their version of a particular feature into the kernel. But sometimes
developers discover they’ve been working along very similar lines, and the
only reason they hadn’t been working together was that they just didn’t know
each other existed.
Recently, Jian-Hong Pan asked if there was any interest in a
he’d been working on. LoRaWAN is a commercial networking protocol
implementing a low-power wide-area network (LPWAN) allowing relatively slow
communications between things, generally phone sensors and other internet of
things devices. Jian-Hong posted a link to the work he’d done so far:
He specifically wanted to know “should we add the definitions into
corresponding kernel header files now, if LoRaWAN will be accepted as a
subsystem in Linux?” The reason he was asking was that each definition had
its own number. Adding them into the kernel would mean the numbers associated
with any future LoRaWAN subsystem would stay the same during development.
However, Marcel Holtmann explained the process:
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.
Meanwhile, Andreas Färber said he’d been working on supporting the same
protocol himself and gave a link to his own proof-of-concept repository:
On learning about Andreas’ work, Jian-Hong’s response was, “Wow! Great! I
get new friends :)”
That’s where the public conversation ended. The two of them undoubtedly
have pooled their energies and will produce a new patch, better than either of
them might have done separately.
Powered by WPeMatico