Messages in this thread | | | Date | Tue, 22 Oct 2002 11:03:07 -0500 | From | Corey Minyard <> | Subject | Re: [PATCH] NMI request/release |
| |
John Levon wrote:
>On Tue, Oct 22, 2002 at 08:02:11AM -0500, Corey Minyard wrote: > >>Ok. I'd be inclined to leave the high-usage things where they are, >>although it would be nice to be able to make the NMI watchdog a module. >>oprofile should probably stay where it is. Do you have an alternate >>implementation that would be more efficient? >> >> >I'm beginning to think you're right. You should ask Keith Owens if kdb >etc. can use your API successfully. > Ok. Good thought, that would decouple kdb a little.
>>>>dev_name could be removed, although it would be nice for reporting >>>> >>>Reporting what ? from where ? >>> >>Registered NMI users in procfs. >> >> >Then if you add such code, you can add dev_name ... I hate code that >does nothing ... > Ok, I'll add a procfs interface then :-). IMHO, there's a different between stuff in an interface that is looking forward and dead code, though. If I added it later, I would break all the users. But there is a balance.
>>Yes. But I don't understand why they would be used in the notifier code. >> >> >I'm trying to reduce code duplication - you do basically the same thing >notifier register/unregister does. > Ah. Yes, there is some stuff that looks the same but is subtly different. I'll see what I can do.
>btw, the stuff you add to header files should all be in asm-i386/nmi.h >IMHO. > Ok, I agree.
>It would make it clear that there's a fast-path "set nmi handler" and >the slow one, and you can document the difference there, if that's what >we're going to do. > >regards >john > > > Thanks,
-Corey
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |