LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* accessing file operations directly in the kernel
@ 2008-11-06 22:39 andy
  0 siblings, 0 replies; 3+ messages in thread
From: andy @ 2008-11-06 22:39 UTC (permalink / raw)
  To: linux-kernel

Hi,

I am dealing with an interesting situation, which I have to access a
serial device driver
from the kernel space. I tried to use sys_open, sys_ioctl ... but
there is a problem
with the file descriptors.  Now, I started using direct calls to the
drivers functions
driver_open, driver_ioctl... passing the *inode from user_path_walk(),
but it doesn't
seem that works right. This serial device is going to be used only
from the other
module that runs in the kernel.

TIA
Andy

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: accessing file operations directly in the kernel
  2008-11-07  1:20 ` Robert Hancock
@ 2008-11-07 14:46   ` andy
  0 siblings, 0 replies; 3+ messages in thread
From: andy @ 2008-11-07 14:46 UTC (permalink / raw)
  To: Robert Hancock; +Cc: linux-kernel

I agree with you! But there are cases where standards
are followed from certain developers. I have to deal with a
very "peculiar" arrangement of a set of requirements to access
a serial device driver. The type of code below gives me what I need, I think.

filp = filp_open("/dev/device1", O_WRONLY, 0);

if (filp->f_op->ioctl(filp->f_dentry->d_inode, filp,
							CMD,
							(unsigned long) &args) != 0) {
        		goto failed;
}

Regards
Andy

On 11/7/08, Robert Hancock <hancockr@shaw.ca> wrote:
> andy wrote:
>
> > Hi,
> >
> > I am dealing with an interesting situation, which I have to access a
> > serial device driver
> > from the kernel space. I tried to use sys_open, sys_ioctl ... but
> > there is a problem
> > with the file descriptors.  Now, I started using direct calls to the
> > drivers functions
> > driver_open, driver_ioctl... passing the *inode from user_path_walk(),
> > but it doesn't
> > seem that works right. This serial device is going to be used only
> > from the other
> > module that runs in the kernel.
> >
>
>  For some reason this kind of question (using file operations inside the
> kernel) gets asked a lot. The short answer is that if you're asking it, you
> likely have a wrong design. It's just not the right thing to do. For one
> thing, file descriptors belong to a process, so just stealing the FD space
> from some random process is unlikely to do the right thing.
>
>  If you really need to do this, adding hooks to the serial device driver
> would seem a more logical thing to do.. but even that seems a suspicious
> design. It would be best if you explained what it is you're actually trying
> to accomplish.
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: accessing file operations directly in the kernel
       [not found] <fa.8yqIDPH3sfvHfyr9YeQyeb9HG/Q@ifi.uio.no>
@ 2008-11-07  1:20 ` Robert Hancock
  2008-11-07 14:46   ` andy
  0 siblings, 1 reply; 3+ messages in thread
From: Robert Hancock @ 2008-11-07  1:20 UTC (permalink / raw)
  To: andy; +Cc: linux-kernel

andy wrote:
> Hi,
> 
> I am dealing with an interesting situation, which I have to access a
> serial device driver
> from the kernel space. I tried to use sys_open, sys_ioctl ... but
> there is a problem
> with the file descriptors.  Now, I started using direct calls to the
> drivers functions
> driver_open, driver_ioctl... passing the *inode from user_path_walk(),
> but it doesn't
> seem that works right. This serial device is going to be used only
> from the other
> module that runs in the kernel.

For some reason this kind of question (using file operations inside the 
kernel) gets asked a lot. The short answer is that if you're asking it, 
you likely have a wrong design. It's just not the right thing to do. For 
one thing, file descriptors belong to a process, so just stealing the FD 
space from some random process is unlikely to do the right thing.

If you really need to do this, adding hooks to the serial device driver 
would seem a more logical thing to do.. but even that seems a suspicious 
design. It would be best if you explained what it is you're actually 
trying to accomplish.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-11-07 14:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-06 22:39 accessing file operations directly in the kernel andy
     [not found] <fa.8yqIDPH3sfvHfyr9YeQyeb9HG/Q@ifi.uio.no>
2008-11-07  1:20 ` Robert Hancock
2008-11-07 14:46   ` andy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).