RE: Help - how to identify the callers in a SCSI lower-leveldriver

RE: Help - how to identify the callers in a SCSI lower-leveldriver

[Lee Xing]

Thanks for the response.

The shim (a pseudo SCSI lower-level driver) we are working on sits in between Linux SCSI mid-level driver and our existing kernel driver which interfaces with a FC driver which interacts with the FC HBA.

To track SCSI initiators' tasks, it would be great if our existing kernel driver knows which application makes the (SCSI passthrough ioctl) call to /dev/sda.

Thanks,


Lee

-----Original Message-----
From: Arjan van de Ven [mailto:arjanv@redhat.com]
Sent: Wednesday, April 07, 2004 3:02 PM
To: Lee Xing
Cc: linux-scsi@vger.kernel.org
Subject: Re: Help - how to identify the callers in a SCSI
lower-leveldriver


On Wed, 2004-04-07 at 21:52, Lee Xing wrote:
> Hi,
> 
> I'm writing a pseudo Linux lower-level SCSI driver, which interfaces with the standard mid-level driver and needs to identify different calling applications in Linux user space.  For example, there are 2 applications, app1 and app2, in user space, and they both use /dev/hda.  We don't need the SCSI lower-level driver to know the applications' names "app1" or "app2", but just need it to tell the (SCSI passthrough ioctl) calls are from the "this" application or from "that" application.


you'll find that most IO's will come from the VM subsystem and not
directly from applications. Why do you think you need this functionality
????

Re: Help - how to identify the callers in a SCSI lower-leveldriver

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Wed, Apr 07, 2004 at 03:42:45PM -0500, Lee Xing wrote:
> Thanks for the response.
> 
> The shim (a pseudo SCSI lower-level driver) we are working on sits in
> between Linux SCSI mid-level driver and our existing kernel driver which
> interfaces with a FC driver which interacts with the FC HBA.

wow that sounds like a great way to kill performance, that many extra layers

> 
> To track SCSI initiators' tasks, it would be great if our existing kernel
> driver knows which application makes the (SCSI passthrough ioctl) call to
> /dev/sda.

well... it's a fundamentally hard problem. For example the application that
submitted the IO may no longer exist on disk by the time you get to see the
IO, or the process may already have exited. It sounds like a fundamentally
fragile/broken concept to use this information for *anything*, it's still
not clear to me what you'd use it for (other than doing a gross hack by
faking IO priorities based on application name but that's sooo not the right
solution to that problem)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Help - how to identify the callers in a SCSI lower-leveldriver

[Abhishek Rai]

> > The shim (a pseudo SCSI lower-level driver) we are working on sits in
> > between Linux SCSI mid-level driver and our existing kernel driver which
> > interfaces with a FC driver which interacts with the FC HBA.
>
> wow that sounds like a great way to kill performance, that many extra layers
>
> >
> > To track SCSI initiators' tasks, it would be great if our existing kernel
> > driver knows which application makes the (SCSI passthrough ioctl) call to
> > /dev/sda.
>
> well... it's a fundamentally hard problem. For example the application that
> submitted the IO may no longer exist on disk by the time you get to see the
> IO, or the process may already have exited. It sounds like a fundamentally
> fragile/broken concept to use this information for *anything*, it's still
> not clear to me what you'd use it for (other than doing a gross hack by
> faking IO priorities based on application name but that's sooo not the right
> solution to that problem)
>

If it is just a feature you want in your development driver, you can do it
at the file system level, e.g., modify an existing file system, or better
still, have a thin stackable file system layer that does that. Then you
can mount the file system on your /dev/sda so that the stackable file
system sits in between the underlying file system and the VFS.

Abhishek