Sonic, your right its much better to have a pair of functions that manage the exchange of the exception table. This would give a module developer the ability to customize the kernel exception handling if needed. I guess you could even put extended functionality for trace buffer support into a module instead of directly into the kernel. That wouldn't be bad would it?
My main point is that having the ability to customize the kernel so that building a module has the flexibility to install/manage an event handler. I have mentioned 3 ideas I think they go on endlessly. 1. 2ddma (I owe you an explaination as to how this works) Basics very fast system calls. Non standard so it needs to be managed with a module. 2. Performance monitor overflow/count down exception handler 3. Trace buffer extended behavior handler Sonic, I think the register and unregister functions should return the previously installed handler and its part of the protocol that the user must replace the origional handler when he is done. Does this make sence? Marc Zhang, Sonic writes: > Hi Marc, > > Changing the event table in run time is possible but dangerous, because > your module walks around the kernel event framework and may break other > drivers that register to the same event vector. In addition, Exporting > the event table directly is not a good way. I think an optional kernel > function, such as "Evt *replace_event_vector(Evt *event)", is better. > > But, I still doubt the benefit to do it. How can interrupt handler > affect the speed of a 2d dma driver? If the delay plus time cost to > handle interrupt is less than the time of 1 line DMA operation, there is > no gain to replace the event vector. There is hardware performance > counter in blackfin, why not use it? > > Sonic > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Marc Hoffman > Sent: Sunday, April 08, 2007 8:06 AM > To: uclinux-dist-devel@blackfin.uclinux.org > Subject: [Uclinux-dist-devel] export extable > > > Some of the things that I have want to do are related specialized > exception handlers. One idea comes to mind with respect to making a fast > dma dispatch mechanism which doesn't actually involve the kernel. > So as not to taint the kernel in some non standard way we might consider > just EXPORT_SYMBOL(extable) so that a kernel loadable module can modify > the exception handler table. > > Places where this seems to be interesting to me are. > > 1. fast 2d-dma drivers for video > > 2. performance modeling drivers i.e. install specialized excpt handler > for performance counters. > > 3. ... > > The key here is that the kernel can be extended with out recompilation. > This might allow us to provide a set of specialized optimized drivers > that reconfigure the kernel at runtime via the module API. > > Does this feature make sense, has anyone else wanted to do something > along these lines. The modification which I'm thinking is very simple > but I think it opens up a lot of doors for the loadable module. > > I think we should do this for isrs as well. > > Marc > > --- > /Users/mmh/r7/uClinux-dist/linux-2.6.x/arch/blackfin/mach-common/entry.S > 2007-04-06 10:23:26.000000000 -0400 > +++ linux-2.6.x/arch/blackfin/mach-common/entry.S 2007-04-06 > 21:07:25.000000000 -0400 > @@ -761,7 +759,7 @@ > .data > #endif > ALIGN > -_extable: > +ENTRY(_extable) > /* entry for each EXCAUSE[5:0] > * This table bmust be in sync with the table in > ./kernel/traps.c > * EXCPT instruction can provide 4 bits of EXCAUSE, allowing 16 > to be user defined > --- /Users/mmh/r7/uClinux-dist/linux-2.6.x/arch/blackfin/kernel/traps.c > 2007-04-06 10:23:25.000000000 -0400 > +++ linux-2.6.x/arch/blackfin/kernel/traps.c 2007-04-06 > 20:25:13.000000000 -0400 > @@ -653,3 +648,10 @@ > dump_stack(); > panic("Unrecoverable event\n"); > } > + > + > +extern unsigned long extable[]; > +EXPORT_SYMBOL(extable); > _______________________________________________ > Uclinux-dist-devel mailing list > Uclinux-dist-devel@blackfin.uclinux.org > http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel _______________________________________________ Uclinux-dist-devel mailing list Uclinux-dist-devel@blackfin.uclinux.org http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
