netdev - Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way supported channels are declared

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: <20220131152345.3fefa3aa@xps13>
Date:   Mon, 31 Jan 2022 15:23:45 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>
Subject: Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way
 supported channels are declared

Hi Alexander,

alex.aring@...il.com wrote on Sun, 30 Jan 2022 16:35:35 -0500:

> Hi,
> 
> On Fri, Jan 28, 2022 at 6:08 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > The idea here is to create a structure per set of channels so that we
> > can define much more than basic bitfields for these.
> >
> > The structure is currently almost empty on purpose because this change
> > is supposed to be a mechanical update without additional information but
> > more details will be added in the following commits.
> >  
> 
> In my opinion you want to put more information in this structure which
> is not necessary and force the driver developer to add information
> which is already there encoded in the page/channel bitfields.

The information I am looking forward to add is clearly not encoded in
the page/channel bitfields (these information are added in the
following patches). At least I don't see anywhere in the spec a
paragraph telling which protocol and band must be used as a function of
the page and channel information. So I improved the way channels are
declared to give more information than what we currently have.

BTW I see the wpan tools actually derive the protocol/band from the
channel/page information and I _really_ don't get it. I believe it only
works with hwsim but if it's not the case I would like to hear
more about it.

> Why not
> add helper functionality and get your "band" and "protocol" for a
> page/channel combination?

This information is as static as the channel/page information, so why
using two different channels to get it? This means two different places
where the channels must be described, which IMHO hardens the work for
device driver writers.

I however agree that the final presentation looks a bit more heavy to
the eyes, but besides the extra fat that this change brings, it is
rather easy to give the core all the information it needs in a rather
detailed and understandable way.

Thanks,
Miquèl