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:	Mon, 28 Jul 2008 22:13:15 +0100
From:	Adrian McMenamin <adrian@...golddream.dyndns.info>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Adrian Bunk <bunk@...nel.org>, linux-sh@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: drivers/sh/maple/maple.c compile error

On Tue, 2008-07-29 at 06:01 +0900, Paul Mundt wrote:
> On Mon, Jul 28, 2008 at 09:51:48PM +0100, Adrian McMenamin wrote:
> > On Tue, 2008-07-29 at 05:44 +0900, Paul Mundt wrote:
> > > On Mon, Jul 28, 2008 at 11:20:12PM +0300, Adrian Bunk wrote:
> > > > Commit 306cfd630a4d121cf4e08b894d8b4c4cf106e57e
> > > > (maple: tidy maple_driver code by removing redundant connect/disconnect)
> > > > causes the following compile error:
> > > > 
> > > > <--  snip  -->
> > > > 
> > > > ...
> > > >   CC      drivers/sh/maple/maple.o
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/sh/maple/maple.c: In function 'attach_matching_maple_driver':
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/sh/maple/maple.c:259: error: 'struct maple_driver' has no member named 'connect'
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/sh/maple/maple.c: In function 'maple_detach_driver':
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/sh/maple/maple.c:272: error: 'struct maple_driver' has no member named 'disconnect'
> > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/sh/maple/maple.c:273: error: 'struct maple_driver' has no member named 'disconnect'
> > > > make[4]: *** [drivers/sh/maple/maple.o] Error 1
> > > > 
> > > > <--  snip  -->
> > > > 
> > > Adrian was supposed to send follow-up patches for this, which never
> > > happened. I thought I had dropped this already, but in this case I'll
> > > just revert it.
> > 
> > Actually I wasn't asked about this, but to submit a fix/replacement for
> > a patch that didn't apply.
> > 
> > I will submit a patch for the whole thing then - as I cannot actually
> > match the commit Adrian has quoted to anything.
> > 
> > I think the problem is that I am trying to get a change in the bus and
> > in the drivers (which have different maintainers) to go in together and
> > that has never quite worked. The code runs fine on my box and has done
> > for months now.
> > 
> This seems to point to a serious problem in your working environment, as
> you are neither able to view commits that are referenced or realize there
> is a problem when patches fail to apply anywhere outside of your home
> directory.
> 

I searched in Linus's tree on kernel.org after I couldn't find it in
mine. I can see the commit (306cfd630a4d121cf4e08b894d8b4c4cf106e57e)
referred to in both trees but it doesn't include any changes to the
maple stuff.


> The problem is that the change you made to maple.c is incomplete, it
> basically should have followed 2 other patches, one removing the logic
> entirely from maple.c, and one removing it from the input driver, before
> killing off the function pointers completely.  You were asked to fix up
> and resend the input patch (which seems not to have happened due to a
> problem in your work environment), but I'm unable to find anything
> bordering on a maple patch that actually cleans up
> attach_matching_maple_driver() and maple_detach_driver()
> connect/disconnect references?
> 

http://lkml.org/lkml/2008/6/15/121 - removes the references from
keyboard
http://lkml.org/lkml/2008/6/15/122 - removes the references from the
headers

> In any event, I'm going to revert this. Once you get your environment
> fixed and are able to send a coherent series, we can revisit this. Dmitry
> has already indicated that taking the input bits through my tree is fine,
> so any process problems there are the least of the problem.

I don't think there is anything wrong with my environment. But I am
happy to submit a new set of patches

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ