Re: [PATCH v2 12/23] netpoll: Introduce netpoll_target configs
From: Mike Waychison <hidden>
Date: 2010-11-09 17:24:59
Also in:
lkml
On Tue, Nov 9, 2010 at 6:20 AM, Greg KH [off-list ref] wrote:
On Tue, Nov 09, 2010 at 05:06:45PM +0800, Am??rico Wang wrote:quoted
On Tue, Nov 09, 2010 at 12:34:24AM -0800, Mike Waychison wrote:quoted
On Mon, Nov 8, 2010 at 8:27 PM, Am??rico Wang [off-list ref] wrote:quoted
On Tue, Nov 09, 2010 at 11:30:24AM +0800, Am??rico Wang wrote:quoted
....quoted
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? Presumably, only NETPOLL_TARGET_DYNAMIC needs CONFIGFS_FS=y ? Maybe none of this matters: NETPOLL_TARGET itself *can* be a module, as it doesn't do anything more than stack a target management layer on top of the existing netpoll code. Nothing in this patchset actually changes anything within netpoll itself. Mike Waychison