> On Tue, 6 Nov 2007 13:13:45 -0800 Greg KH <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
