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: <ZADNAQbmxC3hdgl3@smile.fi.intel.com>
Date:   Thu, 2 Mar 2023 18:21:21 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Henning Schild <henning.schild@...mens.com>
Cc:     Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <markgross@...nel.org>,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v2 2/3] leds: simatic-ipc-leds-gpio: split up into
 multiple drivers

On Thu, Mar 02, 2023 at 04:58:24PM +0100, Henning Schild wrote:
> Am Thu, 2 Mar 2023 17:46:54 +0200
> schrieb Andy Shevchenko <andriy.shevchenko@...ux.intel.com>:
> > On Thu, Mar 02, 2023 at 09:40:09AM +0100, Henning Schild wrote:
> > > Am Wed, 1 Mar 2023 19:28:12 +0200
> > > schrieb Andy Shevchenko <andriy.shevchenko@...ux.intel.com>:  
> > > > On Wed, Mar 01, 2023 at 06:02:14PM +0100, Henning Schild wrote:  

...

> > > > > +	.driver = {
> > > > > +		.name = KBUILD_MODNAME,    
> > > > 
> > > > Strictly speaking this is an ABI (as something may instantiate the
> > > > driver from the user space or elsewhere by this name. At the same
> > > > time this may change with the file name change.
> > > > 
> > > > Personally I prefer explicit string literal here.  
> > > 
> > > Switching from one module to three the names have to change. People
> > > who explicitly loaded the old module which supported multiple
> > > machines, will now how to load either both oŕ know which one to
> > > load.  
> > 
> > Wait, are you telling that now users load modules _manually_?!
> 
> No i am not, the modules all load automatically. I was trying to
> construct a hypothetical case where the name change could affect users
> doing unexpected things.
> 
> > > I personally think the ABI change is acceptable, the assumption
> > > would be that the drivers load automatically anyhow. And since
> > > there are no params i doubt users will have /etc/modprobe.d/ or
> > > /sys/module/ stuff around.
> > > 
> > > And with the split i guess an ABI change can not be fully avoided.
> > > Whether the names is explicit or implicit is another discussion and
> > > just a matter of style. I prefer to stay with the currently used
> > > pattern, it is not un-common in the kernel.  
> > 
> > The problem with that pattern is possible, while unlikely, renaming
> > of the file which triggers this to be updated.
> > 
> > Under sysfs the folder will change its name. If user has a script
> > relying on this, it will be broken. So, I prefer mine.
> 
> Yes, the name of the module will change ... and the location of module
> metadata and params in sysfs, both not a big deal here. Because there
> are no params, and there is not need to modprobe manually.

It's not only one folder AFAIU. Also folder in the drivers will change
its name. Parameters is one thing, the folder presence is another.

Yes, the case is quite unlikely to happen (to break anyone's setup)
that's why I started this with 'Strictly speaking...'. So, seems you
are staying on your side, I will leave this to maintainers. If they
are fine, I will have no objections.

> > > > > +	},    

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ