System calls from kernel space

[James T. Dennis]

I need to modify a kernel module to provide an additional bit
of information through /proc. The data I need is a version
number from an mtd device. So I want to do something like:

f=open("/dev/mtd0");
lseek(f,X,SEEK_SET);
read(f,ver,4);
close(f);

... and then squirrel the version number off in my own
memory space. Then I'll handle all future requests (via
cat /proc/...) from my static copy. (I only care about the
initial value of this shortly after boot).

Part of the problem is that the mtd driver is to be built
as a module, so it will not be available when my proc driver
initializes; thus I'd like to defer this part of my initialization
until the first time that /proc node is access. I'd like to
ensure that the kmod module loading mechanism is invoked to
dynamically load the mtd driver the first time that the data
is needs. (Since I'll only need it the first time, and I
don't care about cases where the MTD has been re-flashed during
my kernel session; I also don't care if/when the mtd driver gets
unloaded).

So the question boils down to this: can I make system calls from
within a kernel module? when can I do so? what are the constraints
(when can I NOT do so)? what are the risks? what are the alternative
approaches?

[Kasper Dupont]

"James T. Dennis" wrote:
>
> I need to modify a kernel module to provide an additional bit
> of information through /proc. The data I need is a version
> number from an mtd device. So I want to do something like:
>
> f=open("/dev/mtd0");
> lseek(f,X,SEEK_SET);
> read(f,ver,4);
> close(f);

For file access from kernel space see this page:
http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html

You might even be able to avoid file access, but I
don't know the internals of the mtd driver.

>
> ... and then squirrel the version number off in my own
> memory space. Then I'll handle all future requests (via
> cat /proc/...) from my static copy. (I only care about the
> initial value of this shortly after boot).
>
> Part of the problem is that the mtd driver is to be built
> as a module, so it will not be available when my proc driver
> initializes; thus I'd like to defer this part of my initialization
> until the first time that /proc node is access.

Didn't you say that your own code was a module?
Anyway it should be simple to delay the reading,
just have a static variable indicating if you have
done the reading.

> I'd like to
> ensure that the kmod module loading mechanism is invoked to
> dynamically load the mtd driver the first time that the data
> is needs.

Any access to a device node for which no driver is
loaded will result in the module loader being
executed. Just ensure the module loader is configured
corectly so it knows which module to load. That is
outside the scope of the module itself. There is also
a function you can execute to get a module loaded. (I
don't remember the name.)

> (Since I'll only need it the first time, and I
> don't care about cases where the MTD has been re-flashed during
> my kernel session; I also don't care if/when the mtd driver gets
> unloaded).

Just make sure that part of your code gets executed
only once.

>
> So the question boils down to this: can I make system calls from
> within a kernel module? when can I do so? what are the constraints
> (when can I NOT do so)? what are the risks? what are the alternative
> approaches?

You should try to avoid system calls from within the
kernel. That is no problem, you can just skip that
layer and use the functions a layer lower.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-...@daimi.au.dk