On Tue, Sep 06, 2005 at 07:32:38PM -0700, Eugene Surovegin wrote: > On Tue, Sep 06, 2005 at 07:19:21PM -0700, Matt Mackall wrote: > > > or a') make this a per-driver feature (e.g. NETIF_F_NETPOLL_CHALENGED) > > > > > > In this case, even if driver cannot handle being called from IRQ > > > context, netconsole still can be used, although in a little more > > > limited fashion, but being safe and not causing lock ups, which, as > > > far as I understand you, it was designed to help debugging in the > > > first place :). > > > > Again, there's basically no point to this at all. It won't catch an > > appreciable number of diagnostics that are not already caught by > > syslog and it won't work with kgdb-over-ethernet, netdump, etc. > > Well, you're simplifying here. There are small embedded systems which > don't have syslogd, serial cable connected. For such systems even > softirq driven netpoll is useful.
I'm fairly familiar with the requirements of embedded systems, thanks. If you're not getting significantly more functionality than the syslogd in, say, busybox (about 4k), then why put it in the kernel? > Anyway, it's much more easier for me to just say to my driver users > that netpoll is broken and isn't supported because of this, than > arguing here. For some reason, I have a wrong impression, that you > would want *more* users of your stuff. Which would I rather have: "netconsole never catches my oopses, it's useless." "netconsole didn't work with my driver, so I tried another card and it works great." -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
