Re: [PATCH 1/5] iTCO_wdt: Expose watchdog properties using platform data

[Lee Jones]

On Wed, 29 Jul 2015, Jean Delvare wrote:

> Hi Lee,
> 
> On Tue, 28 Jul 2015 18:32:16 +0100, Lee Jones wrote:
> > On Tue, 28 Jul 2015, Guenter Roeck wrote:
> > > On 07/28/2015 08:28 AM, Lee Jones wrote:
> > > >On Tue, 28 Jul 2015, Guenter Roeck wrote:
> > > >>Sure, we could have changed it to lowercase, but so far no one bothered.
> > > >>Plus, of course, there is always the element that some maintainers hate
> > > >>that kind of cleanup,
> > > >
> > > >Really?  Surely any kind of clean-up is good clean-up.  Especially as
> > > >Greg KH et. al, have been doing public presentations telling everyone
> > > >that there is always kernel work for anyone who has the time; spelling
> > > >corrections and all.
> > > 
> > > Yes, really. Just try to submit cleanup patches to maintainers other than
> > > Greg and myself, and you'll see. It is a minefield.
> > 
> > Admittedly some of us have our quirks, but I'm happy to challenge
> > anyone that won't accept clean-up patches that make things better.
> 
> I may be one of these, to some degree, under certain circumstances.
> 
> The problem is that what you call "better" may not actually sound
> better to me. Or it might be better in some respect but worse in others.

Granted, there must always be a certain degree of common sense
involved.

> Specifically, your proposal to rename a kernel driver to remove
> capitals, obviously has upsides, but it may also have downsides. Are
> modprobe and friends case-insensitive? If not then renaming the module
> that way may break existing "options" or "blacklist" statements
> in /etc/modprobe.conf, or initialization scripts.

We rename/move/add/remove drivers all the time.  I understand that
you're speaking from a distribution PoV, but you guys have to take
these actions into account as a matter of course.  When you move to a
new kernel, you'll have teams who re-generate the aforementioned
files, or breakages would occur on every single release.

> Such a change may also require some changes on the distribution side,
> from a packaging perspective.

Right, which would be one of the responsibilities of the kernel
package maintainer at any given distro.  How is this any different to
any other kernel up-level?

> Likewise, renaming variables in the code makes it look better, but at
> the cost of making future backports to that driver more difficult.

This is something which has to be taken into consideration, granted.
Looking at this example, I can see 4 backports that happened in the
last 4 years, and each of them would have been trivial to fix.

> And if nothing else, the time you (or others) spend on this, is time
> you won't spend somewhere else where it may be more useful. Or fun.

There is no better way to pass the day than to abide coding standards
and my time is worthless. ;)

> So in the end there's always a balance between the costs and the
> benefits. Which may explain why sometimes some maintainers aren't so
> interested in certain clean-up patches.

If there are technical reasons why 'better' isn't really BETTER, then
I absolutely agree with you, but when I said 'better' before, I really
did mean BETTER.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/