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: <20220605224640.3a09e704.max@enpas.org>
Date:   Sun, 5 Jun 2022 22:46:40 +0200
From:   Max Staudt <max@...as.org>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
Cc:     Vincent Mailhol <mailhol.vincent@...adoo.fr>,
        linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        netdev@...r.kernel.org
Subject: Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild

On Sun, 5 Jun 2022 20:06:41 +0200
Marc Kleine-Budde <mkl@...gutronix.de> wrote:

> On 05.06.2022 19:23:47, Max Staudt wrote:
> > This seemingly splits drivers into "things that speak to hardware"
> > and "things that don't". Except... slcan really does speak to
> > hardware. It just so happens to not use any of BITTIMING or
> > RX_OFFLOAD. However, my can327 (formerly elmcan) driver, which is
> > an ldisc just like slcan, *does* use RX_OFFLOAD, so where to I put
> > it? Next to flexcan, m_can, mcp251xfd and ti_hecc?
> > 
> > Is it really just a split by features used in drivers, and no
> > longer a split by virtual/real?  
> 
> We can move RX_OFFLOAD out of the "if CAN_NETLINK". Who wants to
> create an incremental patch against can-next/master?

Yes, this may be useful in the future. But for now, I think I can
answer my question myself :)

My driver does support Netlink to set CAN link parameters. So I'll just
drop it into the CAN_NETLINK -> RX_OFFLOAD category in Kconfig, unless
anyone objects.


I just got confused because in my mind, I'm still comparing it to
slcan, whereas in reality, it's now functionally closer to all the other
hardware drivers. Netlink and all.

Apologies for the noise! 


Max

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ