[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121119230006.GA2523@kroah.com>
Date: Mon, 19 Nov 2012 15:00:06 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc: Bill Pemberton <wfp5p@...ginia.edu>, linux-kernel@...r.kernel.org,
linux-rdma@...r.kernel.org
Subject: Re: [PATCH 407/493] infiniband: remove use of __devexit
On Mon, Nov 19, 2012 at 03:48:45PM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2012 at 02:06:32PM -0800, Greg KH wrote:
>
> > > 5k isn't a lot, but in the context of 'I have to figure out how to
> > > trim ~1MB off the 3.6 kernel to run it in our smallest hardware' it is
> > > the wrong direction :(
> >
> > It is only 0.138% in the "wrong" direction. Seriously, that's a very
> > tiny percentage here, for an option that people _always_ get wrong, and
> > almost no system does not need. The number of bugs we have had in this
> > area is huge, and by fixing this option like this, it takes them all
> > away.
>
> Sure, it isn't a lot. I don't have any idea about problems
> CONFIG_HOTPLUG causes, but it seems alot of work has gone into making
> this option over the years (the patch to remove it is huge), is there
> no other way to get what you want?
The patch overall, is only 7kb or so. It's the fact that it is just
removing the __dev* markings all over the tree that makes it so "big".
The big change is just in a very few places in the kernel core that
actually do something different depending on CONFIG_HOTPLUG or not.
I could just leave things alone, with CONFIG_HOTPLUG always enabled, but
then people will continue to blindly use the __dev* markings, getting it
wrong at times, but never realizing that they don't do anything anymore.
Because they don't do anything anymore, the right thing to do is just
remove them, which is what Bill's patches do.
Hope this helps explain things better.
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/
Powered by blists - more mailing lists