Re: short description of GeoNetworking

                                                                    to
patch the ath9k driver to actually use the 802.11p wifi band (which is
above the classic 5 GHz wifi 802.11ac band)

That is another issue. It make no sense to merge without having at
least one wifi driver support the needed frequency bands.

I may have simplified the modes of operation too much, sorry for the
confusion. Having the standard (ETSI EN 302 636-1) open (which contains
a visualization of the operating modes), let me try it again.

There is GeoUnicast, which is the most advanced and needs routing and
the cosine calculations to find the intermediary host in range closest
to the target host.

Closest to the target. Opposite to how i interpreted it. I still think
a device in the middle might be better, but that needs a true WiFi
person to comment on it.

quoted

How useful is the stack without unicast?

At first glance, not very much. But considering the use case (e.g. BTP
or DNEM) it is more common to notify all vehicles in range (TSB) or a
certain area (GeoBroadcast) to e.g. warn them of a car crash than to
search for a wrong-way driver and tell him via unicast that he is
driving in the wrong direction. And it's two-thirds of the standard.
Plus (and the most important) it would allow me to focus on more
essential stuff, first (like how to properly inject the gps position
data via netlink in a kernel conform manner) instead of aiming for full
standard conformity all at once (cathedral approach).

So looking at it from this perspective, how does the Linux Foundation
Automotive Grade Linux fit in? Does it have a V2V stack? Is it kernel
or user space? If they have a full implementation, which is open
source, but just out of tree, with a range of applications, would it
be better to spend some time to clean up and merge their code?

   Andrew