lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zhdiv8am.fsf@tynnyri.adurom.net>
Date:   Sun, 16 Feb 2020 17:52:33 +0200
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     David Miller <davem@...emloft.net>, dcbw@...hat.com,
        kuba@...nel.org, bjorn.andersson@...aro.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-wireless@...r.kernel.org
Subject: Re: [PATCH 0/2] Migrate QRTR Nameservice to Kernel

+ linux-wireless

Hi Dave & Dan,

Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org> writes:

> On Thu, Feb 13, 2020 at 07:47:55AM -0800, David Miller wrote:
>> From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
>> Date: Thu, 13 Feb 2020 21:00:08 +0530
>> 
>> > The primary motivation is to eliminate the need for installing and starting
>> > a userspace tool for the basic WiFi usage. This will be critical for the
>> > Qualcomm WLAN devices deployed in x86 laptops.
>> 
>> I can't even remember it ever being the case that wifi would come up without
>> the help of a userspace component of some sort to initiate the scan and choose
>> and AP to associate with.
>> 
>> And from that perspective your argument doesn't seem valid at all.
>
> For the WiFi yes, but I should have added that this QRTR nameservice is being
> used by modems, DSPs and some other co-processors for some offloading tasks.
> So currently, they all depend on userspace ns tool for working. So migrating
> it to kernel can benefit them all.

So the background of this is to get QCA6390[1] (a Qualcomm Wi-Fi 6 PCI
device) supported in ath11k without additional dependencies to user
space. Currently Bjorn's QRTR user space daemon[2] needs to be running
for ath11k to even be able to boot the firmware on the device.

In my opinion a wireless driver should be "self contained", meaning that
it should be enough just to update the kernel and install the firmware
images to /lib/firmware and nothing else should be needed. But without
Mani's patches a user with QCA6390 on her laptop would need to fetch and
install the QRTR daemon (as I doubt distros have it pre-installed)
before getting Wi-Fi working on the laptop. But without Wi-Fi trying to
fetch anything from the internet is annoying, so not a very smooth user
experience.

I assume Dave above refers to iw, wpasupplicant and hostapd but I
consider them very different from QRTR. iw, wpasupplicant and hostapd
are generic wireless user space components using the generic
nl80211/wext interfaces and they work with _all_ upstream drivers. They
are also pre-installed by distros so it's basically plug and go for the
user to get Wi-Fi running.

Also from high level design point of view I don't like the idea that
wireless drivers would start to having vendor specific user components,
like Qualcomm, Marvell, Intel and other vendors having their own daemons
running in addition of generic wireless components (iw/wpas/hostapd).
That would be a quite mess trying to handle backwards compatibility and
all other stable kernel/user space interface requirements.

So to have a smooth out of box experience for ath11k users, I consider
that we need QRTR in the kernel and that's why need Mani's patches[3].

[1] https://www.qualcomm.com/products/fastconnect-6800

[2] https://github.com/andersson/qrtr/

[3] https://patchwork.ozlabs.org/cover/1237353/

    https://patchwork.ozlabs.org/patch/1237355/

    https://patchwork.ozlabs.org/patch/1237354/
    
-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ