public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Uladzislau Koshchanka <koshchanka@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>,
	netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH net] lib: packing: fix shift wrapping in bit_reverse()
Date: Sat, 10 Dec 2022 00:07:59 +0200	[thread overview]
Message-ID: <20221209220759.ilbmtf5htncyhiwq@skbuf> (raw)
In-Reply-To: <20221209220651.i43mxhz5aczhhjgs@skbuf>

On Sat, Dec 10, 2022 at 12:06:51AM +0200, Vladimir Oltean wrote:
> On Sat, Dec 10, 2022 at 12:01:28AM +0300, Uladzislau Koshchanka wrote:
> > Hi Vladimir,
> > 
> > > The problem I see with bitrev8 is that the byte_rev_table[] can
> > > seemingly be built as a module (the BITREVERSE Kconfig knob is tristate,
> > > and btw your patch doesn't make PACKING select BITREVERSE). But PACKING
> > > is bool. IIRC, I got comments during review that it's not worth making
> > > packing a module, but I may remember wrong.
> > 
> > Do you really think it's a problem? I personally would just select
> > BITREVERSE with/without making PACKING tristate. BITREVERSE is already
> > selected by CRC32 which defaults to y, so just adding a select isn't a
> > change in the default. Can't think of a practical point in avoiding
> > linking against 256 bytes here.
> > 
> > In any case, it just doesn't look right to have multiple bit-reverse
> > implementations only because of Kconfig relations.
> 
> Ok, let's use BITREVERSE then. Could you submit your patch formally please?

Also, none of that 'while at it, do XYZ unrelated stuff'. One patch per
logical change please.

  reply	other threads:[~2022-12-09 22:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-07 11:23 [PATCH net] lib: packing: fix shift wrapping in bit_reverse() Dan Carpenter
2022-12-07 12:19 ` Vladimir Oltean
2022-12-07 12:21   ` Dan Carpenter
2022-12-07 12:22     ` Vladimir Oltean
2022-12-07 12:51       ` Dan Carpenter
2022-12-07 13:06         ` Vladimir Oltean
2022-12-07 13:02       ` Vladimir Oltean
2022-12-07 19:41     ` David Laight
2022-12-08 16:58       ` Vladimir Oltean
2022-12-09  8:21 ` Uladzislau Koshchanka
2022-12-09 14:30   ` Vladimir Oltean
2022-12-09 21:01     ` Uladzislau Koshchanka
2022-12-09 22:06       ` Vladimir Oltean
2022-12-09 22:07         ` Vladimir Oltean [this message]
2022-12-10  0:44         ` [PATCH] lib: packing: replace bit_reverse() with bitrev8() Uladzislau Koshchanka
2022-12-12 23:04           ` Vladimir Oltean
2022-12-12 23:30           ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221209220759.ilbmtf5htncyhiwq@skbuf \
    --to=olteanv@gmail.com \
    --cc=error27@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=koshchanka@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox