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 14:33:44 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Greg KH <greg@...ah.com>
Cc:	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, 6 Nov 2007 13:13:45 -0800 Greg KH <greg@...ah.com> wrote:
> 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?
> 

Leave the old interfaces in place, deprecate them, remove them later.  If
at all possible.

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