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]
Date:   Sun, 28 Oct 2018 15:35:05 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Johan Hovold <johan@...nel.org>,
        Lars Poeschel <poeschel@...onage.de>,
        devicetree <devicetree@...r.kernel.org>,
        Samuel Ortiz <sameo@...ux.intel.com>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:NFC SUBSYSTEM" <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH v3 3/5] nfc: pn533: add UART phy driver

On Sun, Oct 28, 2018 at 02:46:24PM +0100, Marcel Holtmann wrote:

> >> +#define VERSION "0.1"
> > 
> > We don't version kernel drivers individually, so please drop this here
> > and below.
> 
> if we don’t then maybe send patches to remove MODULE_VERSION first.
> Otherwise this is totally fine to do.
> 
> There are currently 670 usages of MODULE_VERSION and I have not heard
> anybody looking at removing this.

Should have phrased that differently; versioning modules individually
does not make much sense when we already have a kernel version which is
tied to the driver code in question and which *does* get updated as new
kernels are released (unlike these module version defines, which tend to
stay unchanged).

For USB, we've dropped module versioning entirely and push back whenever
someone proposes to add it back. Other subsystems and particularly old
drivers may still have these macros of course.

In this case, the pn533 driver (and its interface drivers) is one of only
three NFC drivers which have MODULE_VERSION, but maybe it makes sense to
keep it in, if only for consistency with the other pn533 components.

Thanks,
Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ