On Wed, 14 Jun 2006 17:53:08 -0700 Pete Zaitcev <[EMAIL PROTECTED]> wrote:
| On Wed, 14 Jun 2006 17:38:24 -0300, "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> wrote: | | > I think BUG_ON(in_interrupt()) does the job. I'll try it here, and | > if it doesn't trigger I'll submit a patch to Andrew only for | > testing porpuses (ie, not for mainline). | | Luiz, you can't be serious! You have to do a review and write call paths | on a piece of paper or however you prefer to do it. Your testing is | extremely limited as we know, you don't even have a null-modem cable. | So if the patch does not trip in your testing it tells you absolutely | nothing. But even in context of AKPM's tree you can't rely on run-time | checks to pick this sort of things. Hey, take it easy. :) I won't test it in my patches. I'll hack the Serial Core code and add debug code just before every call to those functions we want to know whether they run in interrupt context or not. Yeah, I know, it's still limited because the driver itself can call its methods directly in interrupt context. But I think it's a good start. | And putting a BUG in there is irresponsible too. It's such a critical | subsystem. Drop bytes or return zero modem lines, but do not bug out. Well, I want the easier, fastest and non-questionable way to know whether they are called from an interrupt context or not. The first thing that came to my mind was: blow up everything if it has been called in interrupt context. But I'm open for suggestions, of course. -- Luiz Fernando N. Capitulino _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
