Lazy Newbie Question

Lazy Newbie Question

[Calin A. Culianu]

Whats the best way to do the equivalent of a stat() on a char * pathname
from inside a kernel module?  Don't ask why I need to do this.. I know it
sounds evil but I just need to do it...  Basically I need to find out the
minor number of a device file.

I noticed there's a filp_open() function that is exported and it returns a
struct file *.  I am not sure what the semantics of about 75% of the
fields in that struct are.. and/or how they relate to the well-documented
fields in the libc's struct stat.  Any help/insights would be appreciated.


-Calin

Re: Lazy Newbie Question

[Richard B. Johnson]

On Tue, 21 May 2002, Calin A. Culianu wrote:

> 
> Whats the best way to do the equivalent of a stat() on a char * pathname
> from inside a kernel module?  Don't ask why I need to do this.. I know it
> sounds evil but I just need to do it...  Basically I need to find out the
> minor number of a device file.
> 

No. You never "need to do it". Some user-mode task, somewhere, installs
your module. That same task can open your device and via ioctl() tell
it anything it needs to know.

A "file" is something the kernel handles on behalf of a task. That
task has a context which, amongst other things, allows the kernel
to assign file-descriptors. The kernel is not a task. It does not
have a "context". Of course it can create one and it can steal one.
These are the two methods used inside the kernel to handle "files".

And, unless the kernel task "thread" is permanent, it's a dirty
way of corrupting the kernel.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Lazy Newbie Question

[Calin A. Culianu]

On Tue, 21 May 2002, Richard B. Johnson wrote:

> On Tue, 21 May 2002, Calin A. Culianu wrote:
>
> >
> > Whats the best way to do the equivalent of a stat() on a char * pathname
> > from inside a kernel module?  Don't ask why I need to do this.. I know it
> > sounds evil but I just need to do it...  Basically I need to find out the
> > minor number of a device file.
> >
>
> No. You never "need to do it". Some user-mode task, somewhere, installs
> your module. That same task can open your device and via ioctl() tell
> it anything it needs to know.

Well I need to do it.  I know all about ioctls and the like,
thank-you-very-much.  I am writing code for COMEDI (have you heard of this
driver suite?) which uses a kernel-space API for Realtime Linux
(RTAI/RT-Linux).  So yes, I NEED TO DO IT!  :)

>
> A "file" is something the kernel handles on behalf of a task. That
> task has a context which, amongst other things, allows the kernel
> to assign file-descriptors. The kernel is not a task. It does not
> have a "context". Of course it can create one and it can steal one.
> These are the two methods used inside the kernel to handle "files".
>
> And, unless the kernel task "thread" is permanent, it's a dirty
> way of corrupting the kernel.
>

Yes, as meantioned above.. my thread is permanent.  It is a periodic
realtime priority thread.  However, the stuff that needs to determine
device minors is going to run at non-realtime priority.

At any rate.. please don't chastise me.  I am asking a simple question and
I wanted a straightforward answer.. I didn't expect to be flamed for it.

Have a nice day, Dick.

-Calin

Re: Lazy Newbie Question

[Eli Carter]

Calin A. Culianu wrote:
> At any rate.. please don't chastise me.  I am asking a simple question and
> I wanted a straightforward answer.. I didn't expect to be flamed for it.
> 
> Have a nice day, Dick.
> 
> -Calin

Sadly, l-k is notorious for flames...  expect a flame for just about 
_any_ post to this list.
You might want to try the kernel-newbies list first with questions... 
that list seems less prone to roasting people with near-routine 
questions.  The address for that list is kernelnewbies@nl.linux.org. 
(And yes, accessing a file from the kernel is a fairly routine question 
around here.  Which is part of the reason the first response was a bit 
curt.)

And the footer of a message from the kernel-newbies list has some other 
things you might find helpful:
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/

HTH,

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

Re: Lazy Newbie Question

[Richard B. Johnson]

On Tue, 21 May 2002, Calin A. Culianu wrote:

> On Tue, 21 May 2002, Richard B. Johnson wrote:
> 
> > On Tue, 21 May 2002, Calin A. Culianu wrote:
> >
> > >
> > > Whats the best way to do the equivalent of a stat() on a char * pathname
> > > from inside a kernel module?  Don't ask why I need to do this.. I know it
> > > sounds evil but I just need to do it...  Basically I need to find out the
> > > minor number of a device file.
> > >
> >
> > No. You never "need to do it". Some user-mode task, somewhere, installs
> > your module. That same task can open your device and via ioctl() tell
> > it anything it needs to know.
> 
> Well I need to do it.  I know all about ioctls and the like,
> thank-you-very-much.  I am writing code for COMEDI (have you heard of this
> driver suite?) which uses a kernel-space API for Realtime Linux
> (RTAI/RT-Linux).  So yes, I NEED TO DO IT!  :)
> 

Well the COMEDI I know about, written mostly by David Schleef, does
not require manipulating files in kernel space. This is a collection
of drivers, tools, and libraries for data acquisition.

> >
> > A "file" is something the kernel handles on behalf of a task. That
> > task has a context which, amongst other things, allows the kernel
> > to assign file-descriptors. The kernel is not a task. It does not
> > have a "context". Of course it can create one and it can steal one.
> > These are the two methods used inside the kernel to handle "files".
> >
> > And, unless the kernel task "thread" is permanent, it's a dirty
> > way of corrupting the kernel.
> >
> 
> Yes, as meantioned above.. my thread is permanent.  It is a periodic
> realtime priority thread.  However, the stuff that needs to determine
> device minors is going to run at non-realtime priority.
> 
> At any rate.. please don't chastise me.  I am asking a simple question and
> I wanted a straightforward answer.. I didn't expect to be flamed for it.
> 

My response was hardly a flame. Grep the driver sources for
kernel_thread().  There are important methods of terminating such
threads, if necessary, such as before removing a module. A kernel
thread can use files, but they have to execute sys_open(), etc.,
you do not attempt to use the user-mode trap (int 0x80).


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Lazy Newbie Question

[Calin A. Culianu]

> Well the COMEDI I know about, written mostly by David Schleef, does
> not require manipulating files in kernel space. This is a collection
> of drivers, tools, and libraries for data acquisition.

int kcomedilib_main.c: comedi_t * comedi_open(const char *pathname).

'nuff said.

-Calin

Re: Lazy Newbie Question

[Kevin Buhr]

"Calin A. Culianu" <calin@ajvar.org> writes:
> 
> int kcomedilib_main.c: comedi_t * comedi_open(const char *pathname).

Which version of Comedi are you using?  In comedi-0.7.64 (the most
recent that I can find), I see:

  comedi-0.7.64/comedi/kcomedilib/kcomedilib_main.c:
        int comedi_open(unsigned int minor)

In comedilib-0.7.18, I see:

  comedilib-0.7.18/include/comedilib.h:
        comedi_t *comedi_open(const char *fn);

but of course that version is meant to be called from user space.

I can't find the string "pathname" in any Comedi code anywhere.

> 'nuff said.

On the contrary...

-- 
Kevin Buhr <buhr@telus.net>

Re: Lazy Newbie Question

[Calin A. Culianu]

On 21 May 2002, Kevin Buhr wrote:

> "Calin A. Culianu" <calin@ajvar.org> writes:
> >
> > int kcomedilib_main.c: comedi_t * comedi_open(const char *pathname).
>
> Which version of Comedi are you using?  In comedi-0.7.64 (the most
> recent that I can find), I see:
>
>   comedi-0.7.64/comedi/kcomedilib/kcomedilib_main.c:
>         int comedi_open(unsigned int minor)

Get comedi-cvs.

>
> In comedilib-0.7.18, I see:
>
>   comedilib-0.7.18/include/comedilib.h:
>         comedi_t *comedi_open(const char *fn);
>
> but of course that version is meant to be called from user space.
>
> I can't find the string "pathname" in any Comedi code anywhere.
>
> > 'nuff said.
>
> On the contrary...

Yeah whatever.

>
>

Re: Lazy Newbie Question

[Kevin Buhr]

"Calin A. Culianu" <calin@ajvar.org> writes:
> 
> Get comedi-cvs.

Thanks.

> > > 'nuff said.
> >
> > On the contrary...
> 
> Yeah whatever.

Well, as you can see from the implementation of "comedi_open" that's
right in front of you, that code doesn't do anything with the filename
except parse it as string of the form "/dev/comediNNN" to get the
minor number "NNN".  It looks like a cheesy hack to fake the
kernel-mode interface to look like the user-mode interface, but that's
all it is.  So, as Richard said, we still haven't seen any evidence
that Comedi requires manipulating files in kernel space.

It's quite strange how rude and evasive you're being when everyone
who's replied has been polite and helpful.  Perhaps if you lost the
attitude and told us what it is you're really trying to do, we could
help you more effectively.

I mean, either we're all too dim to understand your device driver
hacking skills, in which case there's no point in you wasting your
time here, or one of us has enough of a clue to help, in which case
we'd all benefit from you explaining your problem as fully as you are
able instead of demanding we show you how to do the impossible (i.e.,
stat a file without a process context).

By the way, in case you missed it---and it seems you did---Richard
already gave you the right answer in the message you mistakenly
dismissed as a flame.  If you really need to stat a file from the
kernel, you do this with a helper process in the form of a bona fide
user process or a kernel thread.  Because this is relatively
complicated to get right (there's a damn good reason the code in
"comedi_open" just fakes it), you don't want to do this unless you
have to.

-- 
Kevin Buhr <buhr@telus.net>

Re: Lazy Newbie Question

[Calin A. Culianu]

On 21 May 2002, Kevin Buhr wrote:

> "Calin A. Culianu" <calin@ajvar.org> writes:
> >
> > Get comedi-cvs.
>
> Thanks.
>
> > > > 'nuff said.
> > >
> > > On the contrary...
> >
> > Yeah whatever.
>
> Well, as you can see from the implementation of "comedi_open" that's
> right in front of you, that code doesn't do anything with the filename
> except parse it as string of the form "/dev/comediNNN" to get the
> minor number "NNN".  It looks like a cheesy hack to fake the
> kernel-mode interface to look like the user-mode interface, but that's
> all it is.  So, as Richard said, we still haven't seen any evidence
> that Comedi requires manipulating files in kernel space.
>
> It's quite strange how rude and evasive you're being when everyone
> who's replied has been polite and helpful.  Perhaps if you lost the
> attitude and told us what it is you're really trying to do, we could
> help you more effectively.
>
> I mean, either we're all too dim to understand your device driver
> hacking skills, in which case there's no point in you wasting your
> time here, or one of us has enough of a clue to help, in which case
> we'd all benefit from you explaining your problem as fully as you are
> able instead of demanding we show you how to do the impossible (i.e.,
> stat a file without a process context).

What the fuck is your problem?  I was merely wondering how to use
path_init/path_walk.  I had to go to the newbie irc channel and they were
much politer and must more helpful.  None of this fucking attitude of "why
do you want to do that that is evil never do that".  Obviously i have a
reason to do it and I don't need you lecturing me.


> By the way, in case you missed it---and it seems you did---Richard
> already gave you the right answer in the message you mistakenly
> dismissed as a flame.  If you really need to stat a file from the
> kernel, you do this with a helper process in the form of a bona fide
> user process or a kernel thread.  Because this is relatively
> complicated to get right (there's a damn good reason the code in
> "comedi_open" just fakes it), you don't want to do this unless you
> have to.

Well I lack the knowledge to do that.  Can you be a bit more specific as
to code examples or whatnot?  Just being vague and saying "you don't need
to do that" is bad.

Anyway I am doing it from module_init() in a module I am writing, so the
current thread context is pretty much a good one.

-Calin

Re: Lazy Newbie Question

[Calin A. Culianu]

On Tue, 21 May 2002, Calin A. Culianu wrote:

> On 21 May 2002, Kevin Buhr wrote:
>
> > Well, as you can see from the implementation of "comedi_open" that's
> > right in front of you, that code doesn't do anything with the filename
> > except parse it as string of the form "/dev/comediNNN" to get the
> > minor number "NNN".  It looks like a cheesy hack to fake the
> > kernel-mode interface to look like the user-mode interface, but that's
> > all it is.  So, as Richard said, we still haven't seen any evidence
> > that Comedi requires manipulating files in kernel space.
> >
> > It's quite strange how rude and evasive you're being when everyone
> > who's replied has been polite and helpful.  Perhaps if you lost the
> > attitude and told us what it is you're really trying to do, we could
> > help you more effectively.
> >
> > I mean, either we're all too dim to understand your device driver
> > hacking skills, in which case there's no point in you wasting your
> > time here, or one of us has enough of a clue to help, in which case
> > we'd all benefit from you explaining your problem as fully as you are
> > able instead of demanding we show you how to do the impossible (i.e.,
> > stat a file without a process context).


I have a process context.  This will be happening from module_init() in a
module I am writing, which, last I checked, uses the process context of
the process that did the system call.

>
>
>
> > By the way, in case you missed it---and it seems you did---Richard
> > already gave you the right answer in the message you mistakenly
> > dismissed as a flame.  If you really need to stat a file from the
> > kernel, you do this with a helper process in the form of a bona fide
> > user process or a kernel thread.  Because this is relatively
> > complicated to get right (there's a damn good reason the code in
> > "comedi_open" just fakes it), you don't want to do this unless you
> > have to.
>

No, I understood what Richard was saying, but he was being kind of rude
and lecturing.  He could have been just factual, sans attitude.

Anyway, if you honestly want to help me, then please enlighten me,
otherwise spare me the lectures.

And the thing that comedi does with /dev/comeiXX is a cheap hack that I
wanted to do away with, which was *why* I was going to try and figure out
the ACTUAL device minor on a vfs character device, in order to fool
comedi_open().

-Calin

Re: Lazy Newbie Question

[Zwane Mwaikambo]

On Tue, 21 May 2002, Calin A. Culianu wrote:

> What the fuck is your problem?  I was merely wondering how to use
> path_init/path_walk.  I had to go to the newbie irc channel and they were
> much politer and must more helpful.  None of this fucking attitude of "why
> do you want to do that that is evil never do that".  Obviously i have a
> reason to do it and I don't need you lecturing me.

Wow, you didn't get along with the other kids did you? So far i see 
absolutely no reason why anybody should lend you a hand (no one gets paid 
for support here), perhaps instead of just blurting out insults at the 
kind folks trying to help you out, you may have tried putting forward 
additional questions as to why they consider the proposed methods evil, 
and wether there are more sane ways of achieving the same result.

Perhaps next time consider using another muscle apart from the one in your 
sphincter to convey your message...

Regards,
	Zwane Mwaikambo

 -- 
http://function.linuxpower.ca