netdev - [RFC] wwan subsystem

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-next>] [day] [month] [year] [list]

Date:   Tue, 25 Feb 2020 11:00:52 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     netdev@...r.kernel.org
Cc:     linux-wireless@...r.kernel.org, Alex Elder <elder@...aro.org>,
        m.chetan.kumar@...el.com, Dan Williams <dcbw@...hat.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: [RFC] wwan subsystem

Hi all,

So I figured it's better to finally send this out rather than think
more about polishing the details or fill in the blanks.

Clearly, there are a lot of blanks, and while today we can identify
netdevs that belong to WWAN devices (for the most part) using the
"wwan" device_type, this isn't really possible with any of the other
bits.

In the first (and only, for now) patch I describe more as to what
this really does and why I think it's needed. Despite being small and
simple for now, I think it presents a step forward over the status
quo.

For the netlink interfaces here, I suppose we need to write a small
library or tool to manage things, though I'm not sure if that perhaps
should be part libmbim or such.

Clearly, however, more communication channels than just netdevs will
be necessary, most devices at least also have a number of TTYs (or
similar) for commands, and many will offer some kind of debug/trace
channel, where I'm not sure how it should be exposed by default
(perhaps a debugfs/relayfs file/channel?)

Some have said I shouldn't work on this because I haven't bothered to
read all of the 3GPP specs, but I think that's a distraction; we clearly
need a way to manage these things, if the 3GPP specs were actually
saying something useful, we wouldn't have ended up with at least three
different ways in the kernel already.

johannes