> I have one more question.  The last parameter of NDINIT is described
> as "the calling process.".  However, if I call it from my driver I
> needn't to be in any process context ... So, is NULL allowed or
> should I use any "kernel process identifier"?

I doubt that pointer may be null (I haven't tried it, but I wouldn't
expect it to work).

You could do what I did, and use init.  But that works only after init
has been started.  Since this happens very soon after mounting the root
filesystem, the window when you have files to access but no init to use
as the accessing process is quite small.

If you want to read files during device autoconfig at boot time, you're
out of luck - there is no filesystem yet at that point.  You'd have to
cobble something together to access the disk the way the boot blocks
do, and build the code to handle the filesystem in question yourself.
It could be done, but it would be *ugly*.

Also, it matters whether you are doing this in interrupt context.
Filesystem access is likely to try to sleep, and you can't sleep in an
interrupt handler.

It's also possible I did something wrong.  The code I wrote seemed to
work, but it's entirely possible I was just lucky.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B