On 7/27/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> I'm OK with this - but might suggest to add something like:
attached
-mike
Index: include/asm-blackfin/irq_handler.h
===
--- include/asm-blackfin/irq_handler.h (revision 3496)
+++ in
On 7/27/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> I would also error out in the request - if the handler isn't in L1
> instruction - since otherwise you will get a double fault...
makes sense and easy to check
> Because exception space stack is limited to 1k - there should be some note to
> lim
On Fri 27 Jul 2007 11:13, Marc Hoffman pondered:
>
> Thanks, I didn't realize all of these complexities thanks for sharing them
> with me. Even though I side on the simplisitc approach I agree with all
> that is said and have a better understanding now for why we are making this
> more complex.
Thanks, I didn't realize all of these complexities thanks for sharing them
with me. Even though I side on the simplisitc approach I agree with all
that is said and have a better understanding now for why we are making this
more complex.
thanks again...
Marc
On 7/27/07, Robin Getz <[EMAIL PROTE
On Thu 26 Jul 2007 22:51, Marc Hoffman pondered:
> I guess I'm looking at this thread curious as to why it needs so much
> deliberation over something so simple which I argue should remain
> simple?
Part of the kernel's job is to protect users from themselves. The other part
of the kernel's job
On Fri 27 Jul 2007 00:56, Mike Frysinger pondered:
> On 7/26/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> > Possibly. Or maybe
> > int set_vector(int, void (*)(void));
> > int restore_vector(int);
> >
> > which just return error codes, save the previous vector internally, and
> > require being p
On Fri 27 Jul 2007 00:56, Mike Frysinger pondered:
> On 7/26/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> > Possibly. Or maybe
> > int set_vector(int, void (*)(void));
> > int restore_vector(int);
> >
> > which just return error codes, save the previous vector internally, and
> > require being p
On 7/26/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> Possibly. Or maybe
> int set_vector(int, void (*)(void));
> int restore_vector(int);
>
> which just return error codes, save the previous vector internally, and
> require being paired.
while returning both errno and pointers in one function i
On 7/26/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> Mike Frysinger wrote:
> > On 7/25/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> >> Mike Frysinger wrote:
> >> > On 4/9/07, Zhang, Sonic <[EMAIL PROTECTED]> wrote:
> >> >> Changing the event table in run time is possible but dangerous,
> >> bec
Mike Frysinger wrote:
> On 7/25/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>> Mike Frysinger wrote:
>> > On 4/9/07, Zhang, Sonic <[EMAIL PROTECTED]> wrote:
>> >> Changing the event table in run time is possible but dangerous,
>> because
>> >> your module walks around the kernel event framework an
On Thu 26 Jul 2007 09:34, Phil Wilshire pondered:
> Bernd Schmidt wrote:
> > This isn't necessarily a safe interface - assume you have two modules
> > which want to replace the same exception vector, and you have the
> > following order:
> > load A
> > load B
> > unload A
> > unload B
> >
On Wed 25 Jul 2007 19:20, Mike Frysinger pondered:
> On 7/25/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> > This isn't necessarily a safe interface - assume you have two modules
> > which want to replace the same exception vector, and you have the
> > following order:
> > load A
> > load B
>
Bernd Schmidt wrote:
Mike Frysinger wrote:
On 4/9/07, Zhang, Sonic <[EMAIL PROTECTED]> wrote:
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 additi
On 7/25/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
Mike Frysinger wrote:
> On 4/9/07, Zhang, Sonic <[EMAIL PROTECTED]> wrote:
>> 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 reg
Mike Frysinger wrote:
> On 4/9/07, Zhang, Sonic <[EMAIL PROTECTED]> wrote:
>> 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
On 4/9/07, Zhang, Sonic <[EMAIL PROTECTED]> wrote:
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
Marc Hoffman wrote:
> Actually thinking about it why do we even bother switching the LVL5
> handler, why not just poke a value some place to say that its a
> deferred exception v.s. a hardware exception? I understand the
> referral but why do we bother installing the handler in a dynamic way?
> I
Bernd,
Actually thinking about it why do we even bother switching the LVL5
handler, why not just poke a value some place to say that its a
deferred exception v.s. a hardware exception? I understand the
referral but why do we bother installing the handler in a dynamic way?
I'm confused on this se
Marc Hoffman wrote:
> 2. hardware dispatches to ex_trap_c unless otherwise handled
> 3. ex_trap_c, modifies the LVL5 hardware event handler so no
> hardware events can occur until the exception finishes (correct)?
> then the exception is deferred to LVL5.
Actually it's only modified
Robin,
I guess we should have both mechanisms.
1. be able to install an exception handler directly into extable
2. be able to install an exception handler into trap_c
I guess there are two pieces of functionality that I'm thinking
about. Both are very different and are used for different purpos
On Mon 9 Apr 2007 07:25, Marc Hoffman pondered:
> The details of the execution enviornment is really important and I
> appreciate the brick thrown.
Marc: I don't think you understood what I meant. It was meant as :
- given that we have all these issues - does it really do what you need?
- befo
Robin, yeah your right it would be very limited based on this thanks
for pointing out all the subtle details. Also your correct the best
one could hope from would be a 2d-dma fast system call that just loads
the pair of mmrs and returns. Which btw is exactly what I
want. Some details need to be
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@blackfi
On Sat 7 Apr 2007 20:05, Marc Hoffman pondered:
> Some of the things that I have want to do are related specialized
> exception handlers.
After thinking about this a little more, (Marc and I briefly discussed this on
Friday, and a few other times), what you are able to do in exception space is
p
linux-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
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(e
26 matches
Mail list logo
