On Wed, 7 Sep 2005 10:19:33 -0700
Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 06, 2005 at 09:02:42PM -0700, Eugene Surovegin wrote:
> > I don't quite understand, you _already_ have deferred processing in
> > netpoll (btw, how good this will work with kgdboe?).
>
> Yes, it exists as a last ditch fallback for cases where we can detect
> deadlock. And it works not at all for kgdboe. Fortunately the fallback
> case rarely coincides with a breakpoint unless you're trying to debug
> the network stack itself (which is asking for trouble).
>
> > If some drivers cannot handle *additional* restriction (nowhere
> > documented, btw), ok, let's have a fallback mode for them, which you
> > _already_ have.
>
> If we have to use the fallback mode all the time on a particular device,
> netpoll has no value on that device. It can't catch the oopses you can't
> already catch most of with syslogd, and it can't be used for kgdb.
> At that point, why bother?
>
> > It's amazing, frankly, you insist that this feature "works just fine",
>
> I have in fact said since the first message in the thread that you
> guys are right, I'm breaking the rules. But I also claim it works fine
> for some hardware. These are not incompatible statements. The second
> is a reminder that this stuff is actually useful to people in its
> current form and that we shouldn't break that.
>
It really sounds like netconsole needs to have a different device hook
instead of start_xmit. It also probably doesn't want to have allocate
an skb. What you want is a synchronous way to send one packet with
interrupts disabled:
(dev->netpoll_send)(dev, packet, len)
Yes, it means fixing lots of device drivers, or maybe a transitional
stub can be set in register_netdevice that uses start_xmit. That is
unsafe, but can used while you go about fixing the other devices.
-
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
