[Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

There is a steady flow of patches which bump driver and module versions.

The differences in views add [1] an email burden, which can be easily avoided
by adding policy into CodingStyle guide.

As an example of such patches: "Succeeded" [2] vs. "Failed" [3].

I think that maintainers summit with major code "pushers" is the right venue
to get the answers on the following questions:
 * Can we come with unified policy about those patches?
 * Can we remove them? If yes, is it possible to replace MODULE_VERSION in all patches to point to kernel version?
 * Does such change fail under category "UAPI changes and we can't change" or not?

Thanks

[1] https://patchwork.kernel.org/patch/9735855/
[2] https://patchwork.ozlabs.org/patch/779864/
[3] https://patchwork.kernel.org/patch/7490321/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Linus Torvalds]

On Sun, Jun 25, 2017 at 12:24 AM, Leon Romanovsky <leon@kernel.org> wrote:
> There is a steady flow of patches which bump driver and module versions.
>
>  * Can we come with unified policy about those patches?

We pretty much *have* a unified policy, it's just that I think rdma is crazy.

The unified policy is pretty much that version codes do not matter, do
not exist, and do not get updated.

Things are supposed to be backwards and forwards compatible, because
we don't accept breakage in user space anyway. So versioning is
pointless, and only causes problems.

It causes problems not just because of the conflict issues, but
because it's fundamentally wrong, and makes driver writers think that
it's ok to change interfaces and use versioning to show they changed.
It's *not* OK.

Sometimes you have feature masks (which just mean that it's ok to
_add_ interfaces rather than change them, and make it possible for
user space to check if the new interface exists), but even that is
generally the exception rather than the rule and should be used very
very carefully and preferably not at all.

                  Linus

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

On Sun, Jun 25, 2017 at 10:32:52AM -0700, Linus Torvalds wrote:
> On Sun, Jun 25, 2017 at 12:24 AM, Leon Romanovsky <leon@kernel.org> wrote:
> > There is a steady flow of patches which bump driver and module versions.
> >
> >  * Can we come with unified policy about those patches?
>
> We pretty much *have* a unified policy, it's just that I think rdma is crazy.
>
> The unified policy is pretty much that version codes do not matter, do
> not exist, and do not get updated.

I'm pretty sure that not everyone is aware of it. Those examples of
"accepted" patches are not from RDMA and maybe it will be awkward to hear,
but in RDMA subsystem we don't allow such patches [1].

My attempt to enforce such policy in other subsystem didn't work [2] and
in addition to that failed attempt, I bombarded internally with customers'
requests who have cargo cult to update those versions anyway ("like everyone else").
This is why I'm proposing to ban those patches and remove their exposure for
the drivers/* completely.

>
> Things are supposed to be backwards and forwards compatible, because
> we don't accept breakage in user space anyway. So versioning is
> pointless, and only causes problems.
>
> It causes problems not just because of the conflict issues, but
> because it's fundamentally wrong, and makes driver writers think that
> it's ok to change interfaces and use versioning to show they changed.
> It's *not* OK.

Great, so why are we continuing to allow patches with MODULE_VERSION and
DRIVER_VERSION changes?

>
> Sometimes you have feature masks (which just mean that it's ok to
> _add_ interfaces rather than change them, and make it possible for
> user space to check if the new interface exists), but even that is
> generally the exception rather than the rule and should be used very
> very carefully and preferably not at all.


[1] https://patchwork.kernel.org/patch/9735855/
[2] https://lkml.org/lkml/2016/7/15/17

>
>                   Linus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Linus Torvalds]

On Sun, Jun 25, 2017 at 11:19 AM, Leon Romanovsky <leon@kernel.org> wrote:
>
> Great, so why are we continuing to allow patches with MODULE_VERSION and
> DRIVER_VERSION changes?

I suspect they just haven't caused problems elsewhere.

And honestly, they aren't that common. Grepping for MODULE_VERSION and
DRIVER_VERSION shows more than I would like, but we're talking
hundreds, not thousands (and lots of them are basically dead, stale
code - ATA etc, or just joke names - usb).

                  Linus

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Sun, Jun 25, 2017 at 11:37:12AM -0700, Linus Torvalds wrote:
> On Sun, Jun 25, 2017 at 11:19 AM, Leon Romanovsky <leon@kernel.org> wrote:
> >
> > Great, so why are we continuing to allow patches with MODULE_VERSION and
> > DRIVER_VERSION changes?
>
> I suspect they just haven't caused problems elsewhere.
>
> And honestly, they aren't that common. Grepping for MODULE_VERSION and
> DRIVER_VERSION shows more than I would like, but we're talking
> hundreds, not thousands (and lots of them are basically dead, stale
> code - ATA etc, or just joke names - usb).

I see it differently, from my point of view, it is pretty active,
especially in the subsystems where new drivers are added more often,
but if you say that the policy exists, it is enough for me.

Thanks

>
>                   Linus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Alexandre Belloni]

Hi,

On 25/06/2017 at 22:05:29 +0300, Leon Romanovsky wrote:
> On Sun, Jun 25, 2017 at 11:37:12AM -0700, Linus Torvalds wrote:
> > On Sun, Jun 25, 2017 at 11:19 AM, Leon Romanovsky <leon@kernel.org> wrote:
> > >
> > > Great, so why are we continuing to allow patches with MODULE_VERSION and
> > > DRIVER_VERSION changes?
> >
> > I suspect they just haven't caused problems elsewhere.
> >
> > And honestly, they aren't that common. Grepping for MODULE_VERSION and
> > DRIVER_VERSION shows more than I would like, but we're talking
> > hundreds, not thousands (and lots of them are basically dead, stale
> > code - ATA etc, or just joke names - usb).
> 
> I see it differently, from my point of view, it is pretty active,
> especially in the subsystems where new drivers are added more often,
> but if you say that the policy exists, it is enough for me.
> 

A while ago, I went and removed all of them from the RTC subsystem.



-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On Sun, Jun 25, 2017 at 11:32:45PM +0200, Alexandre Belloni wrote:
> Hi,
>
> On 25/06/2017 at 22:05:29 +0300, Leon Romanovsky wrote:
> > On Sun, Jun 25, 2017 at 11:37:12AM -0700, Linus Torvalds wrote:
> > > On Sun, Jun 25, 2017 at 11:19 AM, Leon Romanovsky <leon@kernel.org> wrote:
> > > >
> > > > Great, so why are we continuing to allow patches with MODULE_VERSION and
> > > > DRIVER_VERSION changes?
> > >
> > > I suspect they just haven't caused problems elsewhere.
> > >
> > > And honestly, they aren't that common. Grepping for MODULE_VERSION and
> > > DRIVER_VERSION shows more than I would like, but we're talking
> > > hundreds, not thousands (and lots of them are basically dead, stale
> > > code - ATA etc, or just joke names - usb).
> >
> > I see it differently, from my point of view, it is pretty active,
> > especially in the subsystems where new drivers are added more often,
> > but if you say that the policy exists, it is enough for me.
> >
>
> A while ago, I went and removed all of them from the RTC subsystem.

I assume that you are referring to the commit fa5691131a87 ("rtc: remove useless DRV_VERSION").

Let's see how similar patch will be accepted in RDMA, netdev communities.

Thanks

>
>
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Geert Uytterhoeven]

On Mon, Jun 26, 2017 at 6:51 AM, Leon Romanovsky <leon@kernel.org> wrote:
> On Sun, Jun 25, 2017 at 11:32:45PM +0200, Alexandre Belloni wrote:
>> Hi,
>>
>> On 25/06/2017 at 22:05:29 +0300, Leon Romanovsky wrote:
>> > On Sun, Jun 25, 2017 at 11:37:12AM -0700, Linus Torvalds wrote:
>> > > On Sun, Jun 25, 2017 at 11:19 AM, Leon Romanovsky <leon@kernel.org> wrote:
>> > > >
>> > > > Great, so why are we continuing to allow patches with MODULE_VERSION and
>> > > > DRIVER_VERSION changes?
>> > >
>> > > I suspect they just haven't caused problems elsewhere.
>> > >
>> > > And honestly, they aren't that common. Grepping for MODULE_VERSION and
>> > > DRIVER_VERSION shows more than I would like, but we're talking
>> > > hundreds, not thousands (and lots of them are basically dead, stale
>> > > code - ATA etc, or just joke names - usb).
>> >
>> > I see it differently, from my point of view, it is pretty active,
>> > especially in the subsystems where new drivers are added more often,
>> > but if you say that the policy exists, it is enough for me.
>> >
>>
>> A while ago, I went and removed all of them from the RTC subsystem.
>
> I assume that you are referring to the commit fa5691131a87 ("rtc: remove useless DRV_VERSION").
>
> Let's see how similar patch will be accepted in RDMA, netdev communities.

The only version that matters is CONFIG_LOCALVERSION_AUTO=y.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Greg KH]

On Sun, Jun 25, 2017 at 10:05:29PM +0300, Leon Romanovsky wrote:
> On Sun, Jun 25, 2017 at 11:37:12AM -0700, Linus Torvalds wrote:
> > On Sun, Jun 25, 2017 at 11:19 AM, Leon Romanovsky <leon@kernel.org> wrote:
> > >
> > > Great, so why are we continuing to allow patches with MODULE_VERSION and
> > > DRIVER_VERSION changes?
> >
> > I suspect they just haven't caused problems elsewhere.
> >
> > And honestly, they aren't that common. Grepping for MODULE_VERSION and
> > DRIVER_VERSION shows more than I would like, but we're talking
> > hundreds, not thousands (and lots of them are basically dead, stale
> > code - ATA etc, or just joke names - usb).
> 
> I see it differently, from my point of view, it is pretty active,
> especially in the subsystems where new drivers are added more often,

It takes a few years for companies to realize that the version numbers
mean nothing.  So give it time, it will slow down.  Or you can just
delete all of them at once, making it easier for you in the end.

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On Mon, Jun 26, 2017 at 07:00:52AM +0200, Greg KH wrote:
> On Sun, Jun 25, 2017 at 10:05:29PM +0300, Leon Romanovsky wrote:
> > On Sun, Jun 25, 2017 at 11:37:12AM -0700, Linus Torvalds wrote:
> > > On Sun, Jun 25, 2017 at 11:19 AM, Leon Romanovsky <leon@kernel.org> wrote:
> > > >
> > > > Great, so why are we continuing to allow patches with MODULE_VERSION and
> > > > DRIVER_VERSION changes?
> > >
> > > I suspect they just haven't caused problems elsewhere.
> > >
> > > And honestly, they aren't that common. Grepping for MODULE_VERSION and
> > > DRIVER_VERSION shows more than I would like, but we're talking
> > > hundreds, not thousands (and lots of them are basically dead, stale
> > > code - ATA etc, or just joke names - usb).
> >
> > I see it differently, from my point of view, it is pretty active,
> > especially in the subsystems where new drivers are added more often,
>
> It takes a few years for companies to realize that the version numbers
> mean nothing.  So give it time, it will slow down.  Or you can just
> delete all of them at once, making it easier for you in the end.

OK, let's start in small scale and limit myself to MODULE_VERSION at this stage.
https://patchwork.kernel.org/patch/9808651/

Thanks

>
> thanks,
>
> greg k-h

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Levin, Alexander (Sasha Levin)]

On Mon, Jun 26, 2017 at 09:03:32AM +0300, Leon Romanovsky wrote:
>OK, let's start in small scale and limit myself to MODULE_VERSION at this stage.
>https://patchwork.kernel.org/patch/9808651/

Isn't it the case that something like this will actually break the ABI?

I assume that a bunch of different companies have scripts that pull out the module version out of the module and make sure that it's at some value that works with the rest of their tools, right?

I also have to assume that these scripts will horribly break when the value just disappears.

-- 

Thanks,
Sasha

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Mon, Jun 26, 2017 at 03:21:10PM +0000, Levin, Alexander (Sasha Levin) wrote:
> On Mon, Jun 26, 2017 at 09:03:32AM +0300, Leon Romanovsky wrote:
> >OK, let's start in small scale and limit myself to MODULE_VERSION at this stage.
> >https://patchwork.kernel.org/patch/9808651/
>
> Isn't it the case that something like this will actually break the ABI?

From the responses, the answer is NO, it is not ABI.

>
> I assume that a bunch of different companies have scripts that pull out the module version out of the module and make sure that it's at some value that works with the rest of their tools, right?
>
> I also have to assume that these scripts will horribly break when the value just disappears.

It is the same as to rely on console prints as reliable source for those scripts. It is broken by design.

>
> --
>
> Thanks,
> Sasha

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Darren Hart]

On Sun, Jun 25, 2017 at 10:32:52AM -0700, Linus Torvalds wrote:
> On Sun, Jun 25, 2017 at 12:24 AM, Leon Romanovsky <leon@kernel.org> wrote:
> > There is a steady flow of patches which bump driver and module versions.
> >
> >  * Can we come with unified policy about those patches?
> 
> We pretty much *have* a unified policy, it's just that I think rdma is crazy.
> 
> The unified policy is pretty much that version codes do not matter, do
> not exist, and do not get updated.
> 

I make the point internally that without a stable-abi, the driver is not
stand-alone, and so the "version" is easily shown to not be independent
from the kernel version (or the distro package version).

> Things are supposed to be backwards and forwards compatible, because
> we don't accept breakage in user space anyway. So versioning is
> pointless, and only causes problems.
> 
> It causes problems not just because of the conflict issues, but
> because it's fundamentally wrong, and makes driver writers think that
> it's ok to change interfaces and use versioning to show they changed.
> It's *not* OK.
> 
> Sometimes you have feature masks (which just mean that it's ok to
> _add_ interfaces rather than change them, and make it possible for
> user space to check if the new interface exists), but even that is
> generally the exception rather than the rule and should be used very
> very carefully and preferably not at all.
> 

While the module version is clearly a flawed concept for Linux drivers,
I do think we should discuss the problem they are intended to address:
knowing what's in a particular instance of a driver.

I see three categories of changes vendors need to be able to track:

1. Bug Fixes
2. Performance enhancements
3. New Features

The first is easily managed through the stable kernel process. Vendors
ensure bug fixes are pushed back to stable, distros pick them up from
there, done.

The second is split into two categories. Many performance regressions
can be accommodated via the stable kernel rules. Regressions with large
mitigation patches and performance enhancements currently need to be
tracked independently from kernel version as they are backported to
distro / product kernels.

New features also fall into the independent tracking bucket, although
your point about feature masks could reduce that need. Is there a
definitive mechanism for the feature mask approach? I see a lot of
sysfs_filename:value key:value pairs for this kind of thing.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Jiri Kosina]

On Fri, 30 Jun 2017, Darren Hart wrote:

> New features also fall into the independent tracking bucket, although 
> your point about feature masks could reduce that need. Is there a 
> definitive mechanism for the feature mask approach? I see a lot of 
> sysfs_filename:value key:value pairs for this kind of thing.

Adding those sysfs attributes seems like exactly the thing that people 
will keep forgetting to do, as there is no (real) functionality depending 
on them.

I doubt there is any better 'description' of the 'state' of the driver 
than SHA of the topmost commit + the tree it's related to.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Driver and/or module versions

[Darren Hart]

On Mon, Jul 03, 2017 at 10:41:16PM +0200, Jiri Kosina wrote:
> On Fri, 30 Jun 2017, Darren Hart wrote:
> 
> > New features also fall into the independent tracking bucket, although 
> > your point about feature masks could reduce that need. Is there a 
> > definitive mechanism for the feature mask approach? I see a lot of 
> > sysfs_filename:value key:value pairs for this kind of thing.
> 
> Adding those sysfs attributes seems like exactly the thing that people 
> will keep forgetting to do, as there is no (real) functionality depending 
> on them.
> 
> I doubt there is any better 'description' of the 'state' of the driver 
> than SHA of the topmost commit + the tree it's related to.

This is exactly what I have been saying in my inward facing roles. Here
I'm trying to make sure I'm not missing something that makes this not
100% accurate.

For specific things, I could see those sysfs attributes being useful,
but as you say, they are informational only.

-- 
Darren Hart
VMware Open Source Technology Center