linux-kernel - Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

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: <20110126220407.GA29484@core.coreip.homeip.net>
Date:	Wed, 26 Jan 2011 14:04:07 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mark Lord <kernel@...savvy.com>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

On Wed, Jan 26, 2011 at 04:41:07PM -0500, Mark Lord wrote:
> On 11-01-26 02:50 PM, Dmitry Torokhov wrote:
> > On Wed, Jan 26, 2011 at 02:47:18PM -0500, Mark Lord wrote:
> >> On 11-01-26 02:41 PM, Dmitry Torokhov wrote:
> >>>
> >>> I do not consider lsinput refusing to work a regression.
> >>
> >> Obviously, since you don't use that tool.
> >> Those of us who do use it see this as broken userspace compatibility.
> >>
> >> Who the hell reviews this crap, anyway?
> >> Code like that should never have made it upstream in the first place.
> >>
> > 
> > You are more than welcome spend more time on reviews.
> 
> Somehow I detect a totally lack of sincerity there.

No, not really. If we known about Ubuntu's employ of such utility before
we'd try to come up with workaround or updated the utility proactively
so user-visible changes would be limited.

> 
> But thanks for fixing the worst of this regression, at least.
> 
> Perhaps you might think about eventually fixing the bad use of -EINVAL
> in future revisions.  One way perhaps to approach that, would be to begin
> fixing it internally,

Yes, that is on my lest (unless somebody beats me to it). Won't help
with the older kernels though, unfortunately.

> but still returning the same things from the actual
> f_ops->ioctl() routine.

Not sure if this is needed.

> 
> Then eventually provide new ioctl numbers which return the correct -ENOTTY
> (or whatever is best there), rather than converting to -EVINAL at the interface.
> Then a nice multi-year overlap, with a scheduled removal of the old codes some day.
> 
> Then the input subsystem would work more like most other subsystems,
> and make userspace programming simpler and easier to "get correct".

I do not believe that such characterization is called for. We did fix
the breakage that was ABI breakage. The version issue is different. If
we go by what you say _none_ of the versions anywhere can be changed
ever because there might be a program that does not expect new version.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/