linux-kernel - Re: mm snapshot broken-out-2007-11-06-02-32.tar.gz uploaded

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:	Tue, 6 Nov 2007 13:13:45 -0800
From:	Greg KH <greg@...ah.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, linux390@...ibm.com,
	linux-s390@...r.kernel.org, apw@...dowen.org
Subject: Re: mm snapshot broken-out-2007-11-06-02-32.tar.gz uploaded -
	S390x build fails

On Tue, Nov 06, 2007 at 01:10:37PM -0800, Andrew Morton wrote:
> > On Tue, 06 Nov 2007 20:40:02 +0530 Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com> wrote:
> > drivers/s390/char/sclp_cpi_sys.c:242: error: storage size of `system_name_attr' isn't known
> > drivers/s390/char/sclp_cpi_sys.c:264: error: storage size of `sysplex_name_attr' isn't known
> > drivers/s390/char/sclp_cpi_sys.c:287: error: storage size of `system_type_attr' isn't known
> > drivers/s390/char/sclp_cpi_sys.c:317: error: storage size of `system_level_attr' isn't known
> > drivers/s390/char/sclp_cpi_sys.c:333: error: storage size of `set_attr' isn't known
> > make[2]: *** [drivers/s390/char/sclp_cpi_sys.o] Error 1
> > make[1]: *** [drivers/s390/char] Error 2
> > make: *** [drivers/s390] Error 2
> > 
> > The patch git-s390.patch is causing this failure.
> 
> git-s390 newly adds that file.  I suspect that this code works OK for the
> s390 guys (they're using Linux).  But Greg's driver tree basically ports
> their driver to Gregnux, in which nothing works any more.
> 
> Greg, this is turning into a bit of a trainwreck.  Can you please have a
> think about how we can provide a bit of back-compatibility to ease this
> transition rather than just trashing everything?

It's _always_ a trainwreck when I touch anything in the driver core,
look at how many individual patches it took to do a lot of this work
(50+ and still growing).  My method is to introduce the new api, convert
everyone over to it, and then remove the old crappy one.

Now for dealing with external trees, I have _no_ visiblity into them for
the most part.  I can't build s390 stuff (no cross compiler), so I can't
even test their changes.

But, there really should not be that many places that are touching these
types of things that I am currently changing (ksets and ktypes and
subsystems.)

So, how do I do this?  Do I just not let my changes trickle into your
tree, and hold off until I merge them with Linus, hoping that me and Kay
have tested everything good enough?  That way, no build ever should
break, but functionality might not be all working as well as it could
be.

Or we live with some breakage as you pull my stuff into your tree.

Either way, I'm glad to help fix the broken stuff, and I'm also glad to
take the responsibility for getting this all right the first time it
goes to Linus.

What do you think is best to do?

thanks,

greg k-h
-
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/