Selective attach for ide-scsi

PATCH In review Willem Riede 4 participants 7 messages Feb 8, 2004 – Feb 14, 2004 SCSI

Share & tools

Willem Riede

author

2004-02-08 22:43 UTC #0 lore raw

PATCH 1/1 Selective attach for ide-scsi

Today, if you boot 2.6.x with hdd=ide-scsi, ide-scsi will attach to all your Atapi drives, not just hdd, unless you explicitely specified another driver for those.

Given that we don't want people to use ide-scsi for cdroms and cd-writers, that behavior is IMHO suboptimal.

The patch below makes ide-scsi attach ONLY to those drives that you tell it to. So if you want it to handle hdb and hdd, but not hdc, you boot with hdb=ide-scsi hdd=ide-scsi.

Regards, Willem Riede.

drivers/scsi/ide-scsi.c +7 -6

@@ -955,17 +955,18 @@
 	static int warned;
 	int err;
 
-	if (!warned && drive->media == ide_cdrom) {
-		printk(KERN_WARNING "ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device\n");
-		warned = 1;
-	}
-
-	if (!strstr("ide-scsi", drive->driver_req) ||
+	if (!drive->driver_req ||
+	    !strstr(drive->driver_req, "ide-scsi") ||
 	    !drive->present ||
 	    drive->media == ide_disk ||
 	    !(host = scsi_host_alloc(&idescsi_template,sizeof(idescsi_scsi_t))))
 		return 1;
 
+	if (!warned && drive->media == ide_cdrom) {
+		printk(KERN_WARNING "ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device\n");
+		warned = 1;
+	}
+
 	host->max_id = 1;
 	host->max_lun = 1;
 	drive->driver_data = host;

Mikael Pettersson

2004-02-09 08:24 UTC #1 lore raw

Quoted 10 lines · Willem Riede

Today, if you boot 2.6.x with hdd=ide-scsi, ide-scsi will attach to all your Atapi drives, not just hdd, unless you explicitely specified another driver for those.
Given that we don't want people to use ide-scsi for cdroms and cd-writers, that behavior is IMHO suboptimal.
The patch below makes ide-scsi attach ONLY to those drives that you tell it to. So if you want it to handle hdb and hdd, but not hdc, you boot with hdb=ide-scsi hdd=ide-scsi.

The patch I posted, which you apparently didn't like, doesn't require the use of boot-only options: it instead adds a module_param to ide-scsi which allows for greater flexibility.

Personally I never liked that butt-ugly hdX=ide-scsi hack.

/Mikael

Willem Riede

author

2004-02-10 00:06 UTC #2 lore raw

Quoted 12 lines · Mikael Pettersson

Quoted 10 lines · Willem Riede
Today, if you boot 2.6.x with hdd=ide-scsi, ide-scsi will attach to all your Atapi drives, not just hdd, unless you explicitely specified another driver for those.
Given that we don't want people to use ide-scsi for cdroms and cd-writers, that behavior is IMHO suboptimal.
The patch below makes ide-scsi attach ONLY to those drives that you tell it to. So if you want it to handle hdb and hdd, but not hdc, you boot with hdb=ide-scsi hdd=ide-scsi.

Quoted 5 lines

The patch I posted, which you apparently didn't like, doesn't require the use of boot-only options: it instead adds a module_param to ide-scsi which allows for greater flexibility.
Personally I never liked that butt-ugly hdX=ide-scsi hack.

I hear you. There are certainly advantages to use a module parameter rather than a boot argument.

However, there should not be two mechanisms to achieve the same goal. For better or for worse, the hdX=<driver> construction exists, and people are using it. Its use is not limited to ide-scsi.

Since it can very easily be adjusted to achieve the desired selectivety, I believe it is the mechanism of choice.

Does anyone else have an opinion?

Thanks, Willem Riede.

Patrick Mansfield

2004-02-11 20:12 UTC #3 lore raw

Quoted 11 lines · Willem Riede

Quoted 7 lines · Mikael Pettersson
Willem Riede writes:
The patch I posted, which you apparently didn't like, doesn't require the use of boot-only options: it instead adds a module_param to ide-scsi which allows for greater flexibility.
Personally I never liked that butt-ugly hdX=ide-scsi hack.
I hear you. There are certainly advantages to use a module parameter rather than a boot argument.

But module_param allows module arguments when built as a module, and boot arguments when built into the kernel.

Quoted 3 lines

However, there should not be two mechanisms to achieve the same goal. For better or for worse, the hdX=<driver> construction exists, and people are using it. Its use is not limited to ide-scsi.

So does module_param not work because the usage is across modules? That seems odd.

-- Patrick Mansfield

Willem Riede

author

2004-02-14 22:06 UTC #4 lore raw

Quoted 16 lines · Patrick Mansfield

Quoted 11 lines · Willem Riede
Quoted 7 lines · Mikael Pettersson
Willem Riede writes:
The patch I posted, which you apparently didn't like, doesn't require the use of boot-only options: it instead adds a module_param to ide-scsi which allows for greater flexibility.
Personally I never liked that butt-ugly hdX=ide-scsi hack.
I hear you. There are certainly advantages to use a module parameter rather than a boot argument.
But module_param allows module arguments when built as a module, and boot arguments when built into the kernel.

Quoted 6 lines

Quoted 3 lines
However, there should not be two mechanisms to achieve the same goal. For better or for worse, the hdX=<driver> construction exists, and people are using it. Its use is not limited to ide-scsi.
So does module_param not work because the usage is across modules? That seems odd.

I wasn't making myself clear, it seems.

The hdX= construct applies to the entire ide subsystem, which for the vast majority of people means it has to be specified at boot time, as ide is compiled in.

If we were to have an ide-scsi module option to tell it which hdX units to attach to, that would be more flexible than having to tell ide, since I can then rmmod/insmod ide-scsi if I want to change my mind, whereas I must reboot if I need to change what I tell ide.

The advantage of the hdX ide parameter is that it applies to the entire ide subsystem, and therefor influences ide-cd, ide-scsi, ide-tape.

The main reason I see for sticking with the hdX= construct is that I think that introducing competing mechanisms that achieve much the same objective is a bad thing.

Regards, Willem Riede.

Bartlomiej Zolnierkiewicz

2004-02-14 22:48 UTC #5 lore raw

Quoted 35 lines · Willem Riede

Quoted 16 lines · Patrick Mansfield
Quoted 11 lines · Willem Riede
Quoted 7 lines · Mikael Pettersson
Willem Riede writes:
The patch I posted, which you apparently didn't like, doesn't require the use of boot-only options: it instead adds a module_param to ide-scsi which allows for greater flexibility.
Personally I never liked that butt-ugly hdX=ide-scsi hack.
I hear you. There are certainly advantages to use a module parameter rather than a boot argument.
But module_param allows module arguments when built as a module, and boot arguments when built into the kernel.
Quoted 6 lines
Quoted 3 lines
However, there should not be two mechanisms to achieve the same goal. For better or for worse, the hdX=<driver> construction exists, and people are using it. Its use is not limited to ide-scsi.
So does module_param not work because the usage is across modules? That seems odd.
I wasn't making myself clear, it seems.
The hdX= construct applies to the entire ide subsystem, which for the vast majority of people means it has to be specified at boot time, as ide is compiled in.
If we were to have an ide-scsi module option to tell it which hdX units to attach to, that would be more flexible than having to tell ide, since I can then rmmod/insmod ide-scsi if I want to change my mind, whereas I must reboot if I need to change what I tell ide.

Quoted 6 lines

The advantage of the hdX ide parameter is that it applies to the entire ide subsystem, and therefor influences ide-cd, ide-scsi, ide-tape.
The main reason I see for sticking with the hdX= construct is that I think that introducing competing mechanisms that achieve much the same objective is a bad thing.

$ echo ide-scsi>/proc/ide/hdX/driver
or
$ echo "ide-scsi:1">/proc/ide/hdX/settings
or
use HDIO_SET_IDE_SCSI ioctl

and you can change driver from ide-{cd,floppy,tape} to ide-scsi in-fly. You can also use it in reverse direction (ie. from ide-scsi to ide-cd).

What more crap do you need? There is already one /proc setting too much.

Cheers,
--bart

Willem Riede

author

2004-02-14 23:03 UTC #6 lore raw

Quoted 11 lines · Bartlomiej Zolnierkiewicz

Quoted 4 lines
The main reason I see for sticking with the hdX= construct is that I think that introducing competing mechanisms that achieve much the same objective is a bad thing.
$ echo ide-scsi>/proc/ide/hdX/driver
or
$ echo "ide-scsi:1">/proc/ide/hdX/settings
or
use HDIO_SET_IDE_SCSI ioctl

Quoted 4 lines

and you can change driver from ide-{cd,floppy,tape} to ide-scsi in-fly. You can also use it in reverse direction (ie. from ide-scsi to ide-cd).
What more crap do you need? There is already one /proc setting too much.

Nothing.

I was actually arguing that we _don't_ need a new mechanism. And, given that there is a /proc entry to change it (which I didn't realize), there is no downside to the current mechanism.

Thanks, Willem Riede.