> 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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
