On Tue, Nov 9, 2010 at 6:20 AM, Greg KH <greg@xxxxxxxxx> 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@xxxxxxxxx> 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? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html