add scsi changer driver
Subsystems (2)
PATCH 1/1 add scsi changer driver
Hi,
This patch adds a device driver for scsi media changer devices (tape libraries for example).
It exists for quite some time (since 2.2.x or so ...), is used by several people and also is in some vendor kernels (debian, suse, maybe others as well). People bug be from time to time to submit it ;)
Recently I went over it and did some 2.6 cleanups, module parameters and the like. And now, finally, here it is.
Please apply,
Gerd
--- Documentation/scsi-changer.txt | 184 +++++ drivers/scsi/Kconfig | 18 drivers/scsi/Makefile | 1 drivers/scsi/ch.c | 1059 +++++++++++++++++++++++++++++++++ include/linux/chio.h | 168 +++++ include/linux/major.h | 1 include/scsi/scsi.h | 3 7 files changed, 1434 insertions(+)
Documentation/scsi-changer.txt new file +184 -0
@@ -0,0 +1,184 @@ + +README for the SCSI media changer driver +======================================== + +This is a driver for SCSI Medium Changer devices, which are listed +with "Type: Medium Changer" in /proc/scsi/scsi. + +This is for *real* Jukeboxes. It is *not* supported to work with +common small CD-ROM changers, neither one-lun-per-slot SCSI changers +nor IDE drives. + +Userland tools available from: http://bytesex.org/changer.html + + +General Information +------------------- + +First some words about how changers work: A changer has 2 (possibly +more) SCSI ID's. One for the changer device which controls the robot, +and one for the device which actually reads and writes the data. The +later may be anything, a MOD, a CD-ROM, a tape or whatever. For the +changer device this is a "don't care", he *only* shuffles around the +media, nothing else. + + +The SCSI changer model is complex, compared to - for example - IDE-CD +changers. But it allows to handle nearly all possible cases. It knows +4 different types of changer elements: + + media transport - this one shuffles around the media, i.e. the + transport arm. Also known as "picker". + storage - a slot which can hold a media. + import/export - the same as above, but is accessable from outside, + i.e. there the operator (you !) can use this to + fill in and remove media from the changer. + Sometimes named "mailslot". + data transfer - this is the device which reads/writes, i.e. the + CD-ROM / Tape / whatever drive. + +None of these is limited to one: A huge Jukebox could have slots for +123 CD-ROM's, 5 CD-ROM readers (and therefore 6 SCSI ID's: the changer +and each CD-ROM) and 2 transport arms. No problem to handle. + + +How it is implemented +--------------------- + +I implemented the driver as character device driver with a NetBSD-like +ioctl interface. Just grabbed NetBSD's header file and one of the +other linux SCSI device drivers as starting point. The interface +should be source code compatible with NetBSD. So if there is any +software (anybody knows ???) which supports a BSDish changer driver, +it should work with this driver too. + +Over time a few more ioctls where added, volume tag support for example +wasn't covered by the NetBSD ioctl API. + + +Current State +------------- + +Support for more than one transport arm is not implemented yet (and +nobody asked for it so far...). + +I test and use the driver myself with a 35 slot cdrom jukebox from +Grundig. I got some reports telling it works ok with tape autoloaders +(Exabyte, HP and DEC). Some People use this driver with amanda. It +works fine with small (11 slots) and a huge (4 MOs, 88 slots) +magneto-optical Jukebox. Probably with lots of other changers too, most +(but not all :-) people mail me only if it does *not* work... + +I don't have any device lists, neither black-list nor white-list. Thus +it is quite useless to ask me whenever a specific device is supported or +not. In theory every changer device which supports the SCSI-2 media +changer command set should work out-of-the-box with this driver. If it +doesn't, it is a bug. Either within the driver or within the firmware +of the changer device. + + +Using it +-------- + +This is a character device with major number is 86, so use +"mknod /dev/sch0 c 86 0" to create the special file for the driver. + +If the module finds the changer, it prints some messages about the +device [ try "dmesg" if you don't see anything ] and should show up in +/proc/devices. If not.... some changers use ID ? / LUN 0 for the +device and ID ? / LUN 1 for the robot mechanism. But Linux does *not* +look for LUN's other than 0 as default, becauce there are to many +broken devices. So you can try: + + 1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi + (replace ID with the SCSI-ID of the device) + 2) boot the kernel with "max_scsi_luns=1" on the command line + (append="max_scsi_luns=1" in lilo.conf should do the trick) + + +Trouble? +-------- + +If you insmod the driver with "insmod debug=1", it will be verbose and +prints a lot of stuff to the syslog. Compiling the kernel with +CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages alot +because the kernel will translate the error codes into human-readable +strings then. + +You can display these messages with the dmesg command (or check the +logfiles). If you email me some question becauce of a problem with the +driver, please include these messages. + + +Insmod options +-------------- + +debug=0/1 + Enable debug messages (see above, default: 0). + +verbose=0/1 + Be verbose (default: 1). + +init=0/1 + Send INITIALIZE ELEMENT STATUS command to the changer + at insmod time (default: 1). + +check_busy=0/1 + When moving media from/to data transfer elements, check + whenever the device is busy and refuse to move if so + (default: 1). + +timeout_init=<seconds> + timeout for the INITIALIZE ELEMENT STATUS command + (default: 3600). + +timeout_move=<seconds> + timeout for all other commands (default: 120). + +dt_id=<id1>,<id2>,... +dt_lun=<lun1>,<lun2>,... + These two allow to specify the SCSI ID and LUN for the data + transfer elements. You likely don't need this as the jukebox + should provide this information. But some devices don't ... + +vendor_firsts= +vendor_counts= +vendor_labels= + These insmod options can be used to tell the driver that there + are some vendor-specific element types. Grundig for example + does this. Some jukeboxes have a printer to label fresh burned + CDs, which is addressed as element 0xc000 (type 5). To tell the + driver about this vendor-specific element, use this: + $ insmod ch \ + vendor_firsts=0xc000 \ + vendor_counts=1 \ + vendor_labels=printer + All three insmod options accept up to four comma-separated + values, this way you can configure the element types 5-8. + You likely need the SCSI specs for the device in question to + find the correct values as they are not covered by the SCSI-2 + standard. + + +Credits +------- + +I wrote this driver using the famous mailing-patches-around-the-world +method. With (more or less) help from: + + Daniel Moehwald <[email protected]> + Dane Jasper <[email protected]> + R. Scott Bailey <[email protected]> + Jonathan Corbet <[email protected]> + +Special thanks go to + Martin Kuehne <[email protected]> +for a old, second-hand (but full functional) cdrom jukebox which I use +to develop/test driver and tools now. + +Have fun, + + Gerd + +-- +Gerd Knorr <[email protected]>
drivers/scsi/Kconfig +18 -0
@@ -137,6 +137,24 @@ config CHR_DEV_SG If unsure, say N. +config CHR_DEV_SCH + tristate "SCSI media changer support" + depends on SCSI + ---help--- + This is a driver for SCSI media changers. Most common devices are + tape libraries and MOD/CDROM jukeboxes. *Real* jukeboxes, you + don't need this for those tiny 6-slot cdrom changers. Media + changers are listed as "Type: Medium Changer" in /proc/scsi/scsi. + If you have such hardware and want to use it with linux, say Y + here. Check <file:Documentation/scsi-changer.txt> for details. + + If you want to compile this as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read <file:Documentation/modules.txt> and + <file:Documentation/scsi.txt>. The module will be called ch.o. + If unsure, say N. + + comment "Some SCSI devices (e.g. CD jukebox) support multiple LUNs" depends on SCSI
drivers/scsi/Makefile +1 -0
@@ -140,6 +140,7 @@ obj-$(CONFIG_CHR_DEV_OSST) += osst.o obj-$(CONFIG_BLK_DEV_SD) += sd_mod.o obj-$(CONFIG_BLK_DEV_SR) += sr_mod.o obj-$(CONFIG_CHR_DEV_SG) += sg.o +obj-$(CONFIG_CHR_DEV_SCH) += ch.o scsi_mod-y += scsi.o hosts.o scsi_ioctl.o constants.o \ scsicam.o scsi_error.o scsi_lib.o \
drivers/scsi/ch.c new file +1059 -0
1,059 lines not on this page · raw message
include/linux/chio.h new file +168 -0
168 lines not on this page · raw message
include/linux/major.h +1 -0
@@ -101,6 +101,7 @@#define I2O_MAJOR 80/* 80->87 */ #define SHMIQ_MAJOR 85/* Linux/mips, SGI /dev/shmiq */ +#define SCSI_CHANGER_MAJOR 86#define IDE6_MAJOR 88#define IDE7_MAJOR 89
include/scsi/scsi.h +3 -0
@@ -41,6 +41,7 @@ extern const char *const scsi_device_typ#define FORMAT_UNIT 0x04#define READ_BLOCK_LIMITS 0x05#define REASSIGN_BLOCKS 0x07 +#define INITIALIZE_ELEMENT_STATUS 0x07#define READ_6 0x08#define WRITE_6 0x0a#define SEEK_6 0x0b
@@ -65,6 +66,7 @@ extern const char *const scsi_device_typ#define READ_10 0x28#define WRITE_10 0x2a#define SEEK_10 0x2b +#define POSITION_TO_ELEMENT 0x2b#define WRITE_VERIFY 0x2e#define VERIFY 0x2f#define SEARCH_HIGH 0x30
@@ -97,6 +99,7 @@ extern const char *const scsi_device_typ#define PERSISTENT_RESERVE_OUT 0x5f#define REPORT_LUNS 0xa0#define MOVE_MEDIUM 0xa5 +#define EXCHANGE_MEDIUM 0xa6#define READ_12 0xa8#define WRITE_12 0xaa#define WRITE_VERIFY_12 0xae
Signature · 1 line
#define printk(args...) fprintf(stderr, ## args)
[this should go to linux-scsi]
Quoted 1 line
+#include <
linux/version.h>
not needed.
Quoted 1 line
+#include <
asm/system.h>
I doubt you'll need this one.
drivers/scsi/ch.c line 30
Quoted 3 lines
drivers/scsi/ch.c new file +3
-0+#include <asm/uaccess.h> + +#include <linux/chio.h> /* here are all the ioctls */
<linux/*.h> should always go before <asm/*.h>
Quoted 1 line
+#define
MAJOR_NRSCSI_CHANGER_MAJOR
please kill this one
Quoted 1 line
+#include "
scsi.h"
never use this header but always the <scsi/*.h>
Quoted 1 line
+MODULE_SUPPORTED_DEVICE("sch");
no needed thsese days
Quoted 25 lines
drivers/scsi/ch.c new file +24
-0+static int dt_id[CH_DT_MAX ] = { [0 ... (CH_DT_MAX -1 ) ] =-1 }; +static int dt_lun[CH_DT_MAX ]; +module_param_array (dt_id, int,NULL ,0444 ); +module_param_array (dt_lun, int,NULL ,0444 ); + +/* tell the driver about vendor-specific slots */ +static int vendor_firsts[CH_TYPES -4 ]; +static int vendor_counts[CH_TYPES -4 ]; +module_param_array (vendor_firsts, int,NULL ,0444 ); +module_param_array (vendor_counts, int,NULL ,0444 ); + +static char *vendor_labels[CH_TYPES -4 ] = { +"v0" ,"v1" ,"v2" ,"v3" +}; +// module_param_string_array(vendor_labels, NULL, 0444); + +#define dprintk(fmt, arg...) if (debug) \ + printk(KERN_DEBUG "%s: " fmt, ch->name, ##arg) +#define vprintk(fmt, arg...) if (verbose) \ + printk(KERN_INFO "%s: " fmt, ch->name, ##arg) + +/* ------------------------------------------------------------------- */ +static int ioctl32_register (void ) +{
drivers/scsi/ch.c line 217
Quoted 10 lines
drivers/scsi/ch.c new file +10
-0+unsigned int i; +int err; + +for (i =0 ; i <ARRAY_SIZE (ioctl32_cmds); i++) { + err =register_ioctl32_conversion (ioctl32_cmds[i].cmd,NULL ); +if (err >=0 ) + ioctl32_cmds[i].reg++; + } +return 0 ; +}
please implement ->compat_ioctl instead.
drivers/scsi/ch.c line 277
Quoted 5 lines
drivers/scsi/ch.c new file +5
-0+int errno, retries =0 , timeout; +DECLARE_COMPLETION (wait); +Scsi_Request *sr; + + sr =scsi_allocate_request (ch->device,GFP_ATOMIC );
wouldn't a GFP_KERNEL do just fine?
Review
Quoted 2 lines
(quoted diff) +2
-0+ if (NULL == sr) + return -ENOMEM;
normal kernel style would be
if (!s) return -ENOMEM;
Review
Quoted 2 lines
(quoted diff) +2
-0+ list_for_each(item,&ch_devlist) { + tmp = list_entry(item, scsi_changer, list);
list_for_each_entry
Review
Quoted 2 lines
(quoted diff) +2
-0+ list_for_each(item,&ch_devlist) { + tmp = list_entry(item, scsi_changer, list);
dito
Quoted 4 lines
Quoted 1 line
+#include <
linux/version.h>not needed.
Quoted 1 line
+#include <
asm/system.h>I doubt you'll need this one.
Dropped.
Quoted 2 lines
Quoted 1 line
+#define
MAJOR_NRSCSI_CHANGER_MAJORplease kill this one
Done.
Quoted 2 lines
Quoted 1 line
+#include "
scsi.h"never use this header but always the <scsi/*.h>
Done.
Quoted 2 lines
Quoted 1 line
+MODULE_SUPPORTED_DEVICE("sch");
no needed thsese days
Dropped.
Quoted 4 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+static int ioctl32_register(void) +{please implement ->compat_ioctl instead.
Done.
Quoted 3 lines
Review
Quoted 1 line
(quoted diff) +1
-0+ sr = scsi_allocate_request(ch->device, GFP_ATOMIC);wouldn't a
GFP_KERNELdo just fine?
Yes (there was another one of this ...).
Fixed.
Quoted 7 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ if (NULL == sr) + return -ENOMEM;normal kernel style would be
if (!s) return -ENOMEM;
Well, I prefeare the first as it's more readable IMHO.
Quoted 4 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ list_for_each(item,&ch_devlist) { + tmp = list_entry(item, scsi_changer, list);
list_for_each_entry
Oh, a new fancy toy I havn't notices yet ;)
When this was added btw.?
New version of the patch is below.
Gerd
==============================[ cut here ]==============================
Subject: [patch] scsi changer
This patch adds a device driver for scsi media changer devices.
--- Documentation/scsi-changer.txt | 180 +++++ drivers/scsi/Kconfig | 18 drivers/scsi/Makefile | 1 drivers/scsi/ch.c | 1020 +++++++++++++++++++++++++++++++++ include/linux/chio.h | 168 +++++ include/linux/major.h | 1 include/scsi/scsi.h | 3 7 files changed, 1391 insertions(+)
Documentation/scsi-changer.txt new file +180 -0
@@ -0,0 +1,180 @@ + +README for the SCSI media changer driver +======================================== + +This is a driver for SCSI Medium Changer devices, which are listed +with "Type: Medium Changer" in /proc/scsi/scsi. + +This is for *real* Jukeboxes. It is *not* supported to work with +common small CD-ROM changers, neither one-lun-per-slot SCSI changers +nor IDE drives. + +Userland tools available from here: + http://linux.bytesex.org/misc/changer.html + + +General Information +------------------- + +First some words about how changers work: A changer has 2 (possibly +more) SCSI ID's. One for the changer device which controls the robot, +and one for the device which actually reads and writes the data. The +later may be anything, a MOD, a CD-ROM, a tape or whatever. For the +changer device this is a "don't care", he *only* shuffles around the +media, nothing else. + + +The SCSI changer model is complex, compared to - for example - IDE-CD +changers. But it allows to handle nearly all possible cases. It knows +4 different types of changer elements: + + media transport - this one shuffles around the media, i.e. the + transport arm. Also known as "picker". + storage - a slot which can hold a media. + import/export - the same as above, but is accessable from outside, + i.e. there the operator (you !) can use this to + fill in and remove media from the changer. + Sometimes named "mailslot". + data transfer - this is the device which reads/writes, i.e. the + CD-ROM / Tape / whatever drive. + +None of these is limited to one: A huge Jukebox could have slots for +123 CD-ROM's, 5 CD-ROM readers (and therefore 6 SCSI ID's: the changer +and each CD-ROM) and 2 transport arms. No problem to handle. + + +How it is implemented +--------------------- + +I implemented the driver as character device driver with a NetBSD-like +ioctl interface. Just grabbed NetBSD's header file and one of the +other linux SCSI device drivers as starting point. The interface +should be source code compatible with NetBSD. So if there is any +software (anybody knows ???) which supports a BSDish changer driver, +it should work with this driver too. + +Over time a few more ioctls where added, volume tag support for example +wasn't covered by the NetBSD ioctl API. + + +Current State +------------- + +Support for more than one transport arm is not implemented yet (and +nobody asked for it so far...). + +I test and use the driver myself with a 35 slot cdrom jukebox from +Grundig. I got some reports telling it works ok with tape autoloaders +(Exabyte, HP and DEC). Some People use this driver with amanda. It +works fine with small (11 slots) and a huge (4 MOs, 88 slots) +magneto-optical Jukebox. Probably with lots of other changers too, most +(but not all :-) people mail me only if it does *not* work... + +I don't have any device lists, neither black-list nor white-list. Thus +it is quite useless to ask me whenever a specific device is supported or +not. In theory every changer device which supports the SCSI-2 media +changer command set should work out-of-the-box with this driver. If it +doesn't, it is a bug. Either within the driver or within the firmware +of the changer device. + + +Using it +-------- + +This is a character device with major number is 86, so use +"mknod /dev/sch0 c 86 0" to create the special file for the driver. + +If the module finds the changer, it prints some messages about the +device [ try "dmesg" if you don't see anything ] and should show up in +/proc/devices. If not.... some changers use ID ? / LUN 0 for the +device and ID ? / LUN 1 for the robot mechanism. But Linux does *not* +look for LUN's other than 0 as default, becauce there are to many +broken devices. So you can try: + + 1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi + (replace ID with the SCSI-ID of the device) + 2) boot the kernel with "max_scsi_luns=1" on the command line + (append="max_scsi_luns=1" in lilo.conf should do the trick) + + +Trouble? +-------- + +If you insmod the driver with "insmod debug=1", it will be verbose and +prints a lot of stuff to the syslog. Compiling the kernel with +CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages alot +because the kernel will translate the error codes into human-readable +strings then. + +You can display these messages with the dmesg command (or check the +logfiles). If you email me some question becauce of a problem with the +driver, please include these messages. + + +Insmod options +-------------- + +debug=0/1 + Enable debug messages (see above, default: 0). + +verbose=0/1 + Be verbose (default: 1). + +init=0/1 + Send INITIALIZE ELEMENT STATUS command to the changer + at insmod time (default: 1). + +timeout_init=<seconds> + timeout for the INITIALIZE ELEMENT STATUS command + (default: 3600). + +timeout_move=<seconds> + timeout for all other commands (default: 120). + +dt_id=<id1>,<id2>,... +dt_lun=<lun1>,<lun2>,... + These two allow to specify the SCSI ID and LUN for the data + transfer elements. You likely don't need this as the jukebox + should provide this information. But some devices don't ... + +vendor_firsts= +vendor_counts= +vendor_labels= + These insmod options can be used to tell the driver that there + are some vendor-specific element types. Grundig for example + does this. Some jukeboxes have a printer to label fresh burned + CDs, which is addressed as element 0xc000 (type 5). To tell the + driver about this vendor-specific element, use this: + $ insmod ch \ + vendor_firsts=0xc000 \ + vendor_counts=1 \ + vendor_labels=printer + All three insmod options accept up to four comma-separated + values, this way you can configure the element types 5-8. + You likely need the SCSI specs for the device in question to + find the correct values as they are not covered by the SCSI-2 + standard. + + +Credits +------- + +I wrote this driver using the famous mailing-patches-around-the-world +method. With (more or less) help from: + + Daniel Moehwald <[email protected]> + Dane Jasper <[email protected]> + R. Scott Bailey <[email protected]> + Jonathan Corbet <[email protected]> + +Special thanks go to + Martin Kuehne <[email protected]> +for a old, second-hand (but full functional) cdrom jukebox which I use +to develop/test driver and tools now. + +Have fun, + + Gerd + +-- +Gerd Knorr <[email protected]>
drivers/scsi/Kconfig +18 -0
@@ -137,6 +137,24 @@ config CHR_DEV_SG If unsure, say N. +config CHR_DEV_SCH + tristate "SCSI media changer support" + depends on SCSI + ---help--- + This is a driver for SCSI media changers. Most common devices are + tape libraries and MOD/CDROM jukeboxes. *Real* jukeboxes, you + don't need this for those tiny 6-slot cdrom changers. Media + changers are listed as "Type: Medium Changer" in /proc/scsi/scsi. + If you have such hardware and want to use it with linux, say Y + here. Check <file:Documentation/scsi-changer.txt> for details. + + If you want to compile this as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read <file:Documentation/modules.txt> and + <file:Documentation/scsi.txt>. The module will be called ch.o. + If unsure, say N. + + comment "Some SCSI devices (e.g. CD jukebox) support multiple LUNs" depends on SCSI
drivers/scsi/Makefile +1 -0
@@ -140,6 +140,7 @@ obj-$(CONFIG_CHR_DEV_OSST) += osst.o obj-$(CONFIG_BLK_DEV_SD) += sd_mod.o obj-$(CONFIG_BLK_DEV_SR) += sr_mod.o obj-$(CONFIG_CHR_DEV_SG) += sg.o +obj-$(CONFIG_CHR_DEV_SCH) += ch.o scsi_mod-y += scsi.o hosts.o scsi_ioctl.o constants.o \ scsicam.o scsi_error.o scsi_lib.o \
drivers/scsi/ch.c new file +1020 -0
1,020 lines not on this page · raw message
include/linux/chio.h new file +168 -0
168 lines not on this page · raw message
include/linux/major.h +1 -0
@@ -101,6 +101,7 @@#define I2O_MAJOR 80/* 80->87 */ #define SHMIQ_MAJOR 85/* Linux/mips, SGI /dev/shmiq */ +#define SCSI_CHANGER_MAJOR 86#define IDE6_MAJOR 88#define IDE7_MAJOR 89
include/scsi/scsi.h +3 -0
@@ -41,6 +41,7 @@ extern const char *const scsi_device_typ#define FORMAT_UNIT 0x04#define READ_BLOCK_LIMITS 0x05#define REASSIGN_BLOCKS 0x07 +#define INITIALIZE_ELEMENT_STATUS 0x07#define READ_6 0x08#define WRITE_6 0x0a#define SEEK_6 0x0b
@@ -65,6 +66,7 @@ extern const char *const scsi_device_typ#define READ_10 0x28#define WRITE_10 0x2a#define SEEK_10 0x2b +#define POSITION_TO_ELEMENT 0x2b#define WRITE_VERIFY 0x2e#define VERIFY 0x2f#define SEARCH_HIGH 0x30
@@ -97,6 +99,7 @@ extern const char *const scsi_device_typ#define PERSISTENT_RESERVE_OUT 0x5f#define REPORT_LUNS 0xa0#define MOVE_MEDIUM 0xa5 +#define EXCHANGE_MEDIUM 0xa6#define READ_12 0xa8#define WRITE_12 0xaa#define WRITE_VERIFY_12 0xae
Looking through this, the only things I really noticed that need work are:
ch_do_scsi(): It looks like this has an effective reimplementation of scsi_wait_req. We're trying to deprecate the usage of scsi_do_req so we can make it private eventually. What's the reason you can't use scsi_wait_req?
ch_ioctl() (and the compat): since this is a new driver, can't this all be done via sysfs? That way, the user would be able to manipulate it from the command line, and we'd no longer need any of the 32->64 compat glue.
James
Quoted 7 lines · James Bottomley
Looking through this, the only things I really noticed that need work are:
ch_do_scsi(): It looks like this has an effective reimplementation ofscsi_wait_req. We're trying to deprecate the usage ofscsi_do_reqso we can make it private eventually. What's the reason you can't usescsi_wait_req?
Probably historical reasons, I havn't tracked the scsi layer changes for quite some time, so this might simply be a 2.6 cleanup I've missed because of that. Will check ...
Quoted 4 lines
ch_ioctl()(and the compat): since this is a new driver, can't this all be done via sysfs? That way, the user would be able to manipulate it from the command line, and we'd no longer need any of the 32->64 compat glue.
Well, it isn't new, it already exists for many years, just not living in mainline (which I finally want to change now ...).
Gerd
Signature · 1 line
#define printk(args...) fprintf(stderr, ## args)
Quoted 3 lines · Gerd Knorr
Probably historical reasons, I havn't tracked the scsi layer changes for quite some time, so this might simply be a 2.6 cleanup I've missed because of that. Will check ...
OK, Thanks.
Quoted 7 lines
Quoted 4 lines
ch_ioctl()(and the compat): since this is a new driver, can't this all be done via sysfs? That way, the user would be able to manipulate it from the command line, and we'd no longer need any of the 32->64 compat glue.Well, it isn't new, it already exists for many years, just not living in mainline (which I finally want to change now ...).
OK, so could you look at doing the sysfs conversions? These are required before the driver goes in. I can help you when I get back from holiday (in about a week's time).
James