issuing ioctl()'s to an adapter driver wo/ devices

Hi all, I'd like to create some ioctl cmd's for the adapter driver that I am writing. Looking at the code, it seems that the way to do this is to just add an appropriate ioctl cmd to include/scsi/sg.h and the scsi upper/mid layers will eventually call the adapter's ioctl() function after not rec

Re: issuing ioctl()'s to an adapter driver wo/ devices

[EMAIL PROTECTED] said: > 2. Hack - have the adapter driver report a phony scsi device > Similar to what scsi_debug does I could create a bogus device and > then be able to do what i need by opening that device. I don't like > this idea much. You wouldn't have to report a phony device, just

Re: issuing ioctl()'s to an adapter driver wo/ devices

> nothing other than sg will bind anyway. This seems like a reasonable > convention for drivers like yours and requires no modifications to the > current SCSI subsystem. Precisely that is the point. If that feature is common, it should be implemented in common code. However this device is not l

Simulate a SCSI disk

I would like to set up a linux computer to act as a SCSI disk on SCSI bus. (linux is target instead of initiator) Can anyone tell me if there are or are not any hardware or firmware issues making this impossible? Also, would I have to modify the low level driver for the scsi-card, or would a pa

Re: Simulate a SCSI disk

[EMAIL PROTECTED] said: > Can anyone tell me if there are or are not any hardware or firmware > issues making this impossible? That depends on the chipset in the bus adapter and the way the adapter is wired. By and large, most modern chipsets will act as a target (I can only say this for cert

Stop rewind in MT command?

I am using mt-st v. 0.5b. At the end of EVERY MT command, a rewind is issued. What good it a seek to end of data (seod) if it is immeadiately rewound before another command can be issued? Is there an option or setting somewhere to stop the rewind command at the end of MT execution? Alan - /-

Re: Stop rewind in MT command?

Alan Dayley wrote: > > I am using mt-st v. 0.5b. At the end of EVERY MT command, a rewind is > issued. What good it a seek to end of data (seod) if it is immeadiately > rewound before another command can be issued? > > Is there an option or setting somewhere to stop the rewind command at the >

Re: Stop rewind in MT command?

On Thu, May 24, 2001 at 09:24:33PM -0400, Doug Ledford wrote: > FILES >/dev/st* : the auto-rewind SCSI tape devices >/dev/nst* : the non-rewind SCSI tape devices In general, is there a way to have a "non-rewind" disk device? I know it doesn't make sense... but... I was thinking

Re: Stop rewind in MT command?

On Thu, 24 May 2001, Mike Castle wrote: > On Thu, May 24, 2001 at 09:24:33PM -0400, Doug Ledford wrote: > > FILES > >/dev/st* : the auto-rewind SCSI tape devices > >/dev/nst* : the non-rewind SCSI tape devices > > > In general, is there a way to have a "non-rewind" disk device?

Re: issuing ioctl()'s to an adapter driver wo/ devices

Mike Brown wrote: > > Hi all, > > I'd like to create some ioctl cmd's for the adapter driver that I am > writing. Looking at the code, it seems that the way to do this is to > just add an appropriate ioctl cmd to include/scsi/sg.h and the I'm not sure sg.h is the correct place to put your adap

Re: Stop rewind in MT command?

On Thu, May 24, 2001 at 10:26:07PM -0400, Hactar wrote: > On Thu, 24 May 2001, Mike Castle wrote: > > > On Thu, May 24, 2001 at 09:24:33PM -0400, Doug Ledford wrote: > > > FILES > > >/dev/st* : the auto-rewind SCSI tape devices > > >/dev/nst* : the non-rewind SCSI tape devices >

Re: Stop rewind in MT command?

Mike Castle wrote: > On Thu, May 24, 2001 at 10:26:07PM -0400, Hactar wrote: > > On Thu, 24 May 2001, Mike Castle wrote: > > > > > On Thu, May 24, 2001 at 09:24:33PM -0400, Doug Ledford wrote: > > > > FILES > > > >/dev/st* : the auto-rewind SCSI tape devices > > > >/dev/nst* : th

Re: Stop rewind in MT command?

On Fri, May 25, 2001 at 08:22:38AM +0200, Rogier Wolff wrote: > What's wrong with putting a filesystem on the zipdisk? Well damned. For some reason I was sure I'd tried that before and it hadn't worked. But I just verified both tar and dump handle the situation correctly. Thanks for the enlig

[PATCH] sd.c - null ptr fixes for 2.4.4

Hi, This patch fixes a couple of errors in the scsi driver code (sd.c). Praveen Srinivasan and Frederick Akalin --- ../linux/./drivers/scsi/sd.cSat Feb 3 11:45:55 2001 +++ ./drivers/scsi/sd.c Mon May 7 22:09:58 2001 @@ -734,8 +734,15 @@ */ SRpnt = scsi_allocate_reque

[PATCH] memory leak in scsi_proc.c

Hi, If someone writes to a scsi adapter's /proc entry and that scsi adapter has not defined a proc_info() entry point, proc_scsi_write() will leak a page. Furthermore, no sense asking for a page if said proc_info() entry point does not exist. This patch fixes the above problem and patches clean

Re: [PATCH] sd.c - null ptr fixes for 2.4.4

> This patch fixes a couple of errors in the scsi driver code (sd.c). > > --- ../linux/./drivers/scsi/sd.c Sat Feb 3 11:45:55 2001 > +++ ./drivers/scsi/sd.c Mon May 7 22:09:58 2001 > @@ -734,8 +734,15 @@ >*/ > > SRpnt = scsi_allocate_request(rscsi_disks[i].device); >