On Tue, Sep 06, 2005 at 08:35:32PM -0700, Matt Mackall wrote: > On Tue, Sep 06, 2005 at 08:19:34PM -0700, David S. Miller wrote: > > From: Matt Mackall <[EMAIL PROTECTED]> > > Date: Tue, 6 Sep 2005 20:08:10 -0700 > > > > > Think upon the kgdb-over-ethernet case, please. The kernel hits a > > > breakpoint, the kgdb stub stops everything, sends a packet to the > > > debugging client, waits for a packet back.. This simply can't work if > > > we delay send/receive to the next softirq processing. > > > > Networking is asynchronous, kgdb-over-ethernet wants synchronous > > processing from an asynchronous subsystem. It is therefore no > > surprise that these two sets of requirements are at odds with each > > other and it simply isn't going to work very well. > > Serial is also asynchronous. And yet we have robust polling support > for typical serial hardware that works great for both console and > remote debugging support. Why? Because delivering kernel messages > synchronously has been a requirement for the serial console since day > one.
Because, serial console has completely isolated code for polled serial access. Serial console doesn't use the same entry point as ordinary serial char device. Using the same approach for networking will require *isolated* polling mode network driver. -- Eugene - 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
