[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101109172713.GA11073@kroah.com>
Date: Tue, 9 Nov 2010 09:27:13 -0800
From: Greg KH <greg@...ah.com>
To: Mike Waychison <mikew@...gle.com>
Cc: Am??rico Wang <xiyou.wangcong@...il.com>,
simon.kagstrom@...insight.net, davem@...emloft.net,
nhorman@...driver.com, Matt Mackall <mpm@...enic.com>,
adurbin@...gle.com, linux-kernel@...r.kernel.org,
chavey@...gle.com, akpm@...ux-foundation.org,
linux-api@...r.kernel.org
Subject: Re: [PATCH v2 12/23] netpoll: Introduce netpoll_target configs
On Tue, Nov 09, 2010 at 09:24:33AM -0800, Mike Waychison wrote:
> On Tue, Nov 9, 2010 at 6:20 AM, Greg KH <greg@...ah.com> wrote:
> > On Tue, Nov 09, 2010 at 05:06:45PM +0800, Am??rico Wang wrote:
> >> On Tue, Nov 09, 2010 at 12:34:24AM -0800, Mike Waychison wrote:
> >> >On Mon, Nov 8, 2010 at 8:27 PM, Am??rico Wang <xiyou.wangcong@...il.com> wrote:
> >> >> On Tue, Nov 09, 2010 at 11:30:24AM +0800, Am??rico Wang wrote:
> >> >>>
> >> >> ....
> >> >>>
> >> >>>So, either we need to de-modulize configfs or replace configfs API
> >> >>>with sysfs API. Personally, I prefer the former one, I don't think
> >> >>>configfs should be a module as long as it can provide API's
> >> >>>for other subsystems, like debugfs.
> >> >>>
> >> >>
> >> >> To clarify, I meant "as long as the API it provides can be used by
> >> >> other core subsystems".
> >> >>
> >> >
> >> >Ya, I see the problem with it being a tristate.
> >> >
> >> >Why not just make netconsole support being compiled in force configfs
> >> >to be compiled in? Or does that just set bad precedent?
> >>
> >> That is what netconsole does now, and this is fine, since netconsole is
> >> a module too, however, after you move that code into netpoll, then netpoll
> >> will have a dependence on it, we will have problems.
> >>
> >> I think we can let NETPOLL_TARGET depend on CONFIGFS_FS=y, but I still
> >> see no reason why CONFIGFS_FS should be a module.
> >
> > No, just have the NETPOLL_TARGET set CONFIG_FS to y, don't force the
> > code to always be that way if the user isn't going to want that option.
>
> Can you clarify what you mean by "that way" here?
I think I can't remember, as this is a bit complex.
I'm just objecting to the changing of configfs to only be able to be
built into the kernel. If this patch set requires configfs, great, then
set the value to "Y", but don't change configfs like the proposed patch
later in this email thread did.
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