Re: Can current macro be accessed from interrupt context?

[Leonidas .]

>
> So given that the process ID is quite often totally pointless, what were you
> trying to accomplish by getting the process ID?
>

I am glad that you asked this question. Actually, what I am trying to
do may not be
even feasible in kernel space. Just spending some cycles on checking
the feasibility.

Here is what I am trying to do.

I am trying to emulate thread local storage in kernel space. Only conceptually.
In user space, multithreaded programs can avoid locking issues by keeping
per thread data structures, as per my understanding in kernel space there is
no such notion. Per cpu data structures is not quite the same thing
since locking
can be avoided only for accessing data local to that cpu, for
accessing data belonging
to other cpus, we would still need some locking mechanism.

Assume that, a multithreaded app talks to my kernel module using
/dev/node, and I need
to book keep certain data in kernel module. The data I am book keeping
can be kept in a
central data structure protected by spinlocks. A better way would be
per cpu data structure.

My idea is to keep data specific to each task which is talking to my
kernel module. Assumption
here is a certain task can be in kernel mode only on one cpu at a time
hence that task specific
data structure can be accessed without locks. All book keeping which
needs to be done in ISRs
would be just book keeping for the interrupted task, i.e. we would
populate interrupted task's
data structure. This is where current comes in picture.

-Leo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/