Re: [PATCH] 2.5.14 IDE 56

Re: [PATCH] 2.5.14 IDE 56

[Andries.Brouwer]

    I'm more worried about the issue of "I installed RH-x.x, and then I
    upgraded the kernel, and now program xyz won't work any more", where "xyz"
    is something perfectly reasonable and common.

    For example, let's say that some strange version of "mount" _requires_
    /proc/ide to work (don't ask me why), and that Mandrake happened to ship
    that version in their 8.2 release, and if you use the new 2.5.15 kernel on
    that installation, it simply won't work. THAT would be a problem where
    some backwards compatibility crud is probably worth it.

First, beautiful things are happening to the IDE code. (*)
Insertion of backwards compatibility crud can be delayed
to just before 2.6 is released.

In the meantime, user space software can be fixed.

Second, no doubt some programs will be affected a little.
[For example, fdisk reads /proc/ide/%s/media and if that says
cdrom or tape it will skip the device. There are other similar,
non-essential, uses.]

Andries


(*) Last time I reported (i) immediate death at boot, and
(ii) HPT366 problems. Now that (i) has been fixed, let me
mention that (ii) has not been fixed yet. Disks hanging off
a HPT366 work well under 2.4.17 but kill the system
(with an infinite stream of "lost interrupt"s or so)
under 2.5.13. Maybe not immediately, but within a few hours.
Bad disk corruption has also been observed.

Linux-2.5.14..

[Linus Torvalds]

There's a lot of stuff that has happened in the 2.5.x series lately, and
you can see the gory details in the ChangeLog files that accompany
releases these days, but I thought I'd point out 2.5.14, since it has some
interesting fundamental changes to how dirty state is maintained in the
VM.

(The big changes were actually in 2.5.12, but 2.5.13 contained various
minor fixes and tweaks, and 2.5.14 contains a number of fixes especially
wrt truncate, so hopefully it's fairly _stable_ as of 2.5.14.)

Credit goes to Andrew Morton, and not only does it clean up the code a
lot, it also seems to perform a lot better in many circumstances.

There's a lot of other stuff in the 2.5.x tree too, but few things are so
fundamental. Please test (but also, please be careful - backups are always
a good idea).

		Linus

[PATCH] 2.5.14 IDE 56

[Martin Dalecki]

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

Mon May  6 13:29:44 CEST 2002 ide-clean-56

- Push poll_timeout down from the hwgroup to the channel. We are resetting the
   channel and not a whole hwgroup. This way using multiple pdc202xxx cards
   should magically start to work with multiple performance and resets will no
   longer lock the system.

- Updates for PDC4030 by Peter Denison <peterd@marshadder.uklinux.net>.

- Make ide_raw_taskfile don't care about request buffers. They where always
   NULL.

- Port set multi mode count over from the special setting interface to
   ide_raw_taskfile. Fix errors in the corresponding interrupt handler in one go
   as well. It turned out that this is precisely the same code as in
   task_no_data_intr, so we can nuke it altogether. And finally we have found
   some problems with the set_pio_mode() command which can fail with -EBUSY -
   this is in esp. probably *very* common during boot hdparm usage those days!
   (OK it was masked by reportig too early that it finished...  Crap Crap utter
   crap it was!!!) Right now hdparm should just be extendid to properly
   sync and retry on   -EBUSY and everything should be fine.

   And now the 1 Milion EUR question for everybody who loves to put driver
   settings in to /proc:

   How the hell could echo > /proc/ide/ide0/settings blah blah blah blah handle
   properly cases like -EIO, -EBUSY and so on??? Having the possibility o do it
   does not mean that it is a good idea to use it.

   OK. After realizing the simple fact that quite a lot of low level hardware
   manipulating ioctls may require assistance in usage from proper logic which is
   *very* unlikely to be implemented in a bash (for me preferable still ksh) I
   have made my mind up.

	/proc/ide will be nuked.

- Execute the recalibration for error recovery on precisely the same request as
   the one which failed.

- Remove set geometry.  It's crap by means of standard specification. Because:

   1. We relay on the existence of the identify command anyway.

   2. This command was obsoleted *before* the identify command existed as far
   as I can see.

   2. I'm able to have a look at what other ATA/ATAPI drivers in the wild do:
   They don't do it.

- Just call tuneproc in set_pio_mode() directly - we are already behind the rq
   queue there.

- After we have uncovered the broken logics behind the whole ioctl handling we
   now just have made ide_spin_wait_hwgroup() waiting for a proper somehow
   longer timeout before giving up. This was previously just hiding the broken
   concept of setting ioctl values through /proc/ide/ideX/settings - now it just
   really helps hdparm to not to give up too early. (It shouldn't probably play
   wreck havock on the global driver spin lock as well. I will look in to this
   later.)

- Scrap the non necessary, to say the least, disabling of interrupts for 3,
   read it again please, 3 seconds, on the local CPU inside
   ide_spin_wait_hwgroup().  Spin lock handling needs checking there badly as I
   see now as well...

Hey apparently any "special" requests are gone. We now have only
to deal with REQ_DEVICE_ACB and REQ_DEVICE_CMD. One of them is still too
much and will be killed.


[-- Attachment #2: ide-clean-56.diff --]
[-- Type: text/plain, Size: 35121 bytes --]

diff -urN linux-2.5.14/drivers/ide/ide.c linux/drivers/ide/ide.c
--- linux-2.5.14/drivers/ide/ide.c	2002-05-07 02:36:37.000000000 +0200
+++ linux/drivers/ide/ide.c	2002-05-07 02:15:18.000000000 +0200
@@ -193,7 +193,7 @@
 #ifdef CONFIG_BLK_DEV_HD
 	if (ch->io_ports[IDE_DATA_OFFSET] == HD_DATA)
 		ch->noprobe = 1; /* may be overridden by ide_setup() */
-#endif /* CONFIG_BLK_DEV_HD */
+#endif
 	ch->major = ide_major[index];
 	sprintf(ch->name, "ide%d", index);
 	ch->bus_state = BUSSTATE_ON;
@@ -201,15 +201,14 @@
 	for (unit = 0; unit < MAX_DRIVES; ++unit) {
 		struct ata_device *drive = &ch->drives[unit];
 
-		drive->type			= ATA_DISK;
-		drive->select.all		= (unit<<4)|0xa0;
-		drive->channel			= ch;
-		drive->ctl			= 0x08;
-		drive->ready_stat		= READY_STAT;
-		drive->bad_wstat		= BAD_W_STAT;
-		drive->special_cmd = (ATA_SPECIAL_RECALIBRATE | ATA_SPECIAL_GEOMETRY);
+		drive->type		= ATA_DISK;
+		drive->select.all	= (unit<<4)|0xa0;
+		drive->channel		= ch;
+		drive->ctl		= 0x08;
+		drive->ready_stat	= READY_STAT;
+		drive->bad_wstat	= BAD_W_STAT;
 		sprintf(drive->name, "hd%c", 'a' + (index * MAX_DRIVES) + unit);
-		drive->max_failures		= IDE_DEFAULT_MAX_FAILURES;
+		drive->max_failures	= IDE_DEFAULT_MAX_FAILURES;
 
 		init_waitqueue_head(&drive->wqueue);
 	}
@@ -354,11 +353,8 @@
 	spin_unlock_irqrestore(&ide_lock, flags);
 }
 
-static void ata_pre_reset(struct ata_device *drive)
+static void check_crc_errors(struct ata_device *drive)
 {
-	if (ata_ops(drive) && ata_ops(drive)->pre_reset)
-		ata_ops(drive)->pre_reset(drive);
-
 	if (!drive->using_dma)
 	    return;
 
@@ -392,38 +388,6 @@
 	return ~0UL;
 }
 
-/*
- * This is used to issue WIN_SPECIFY, WIN_RESTORE, and WIN_SETMULT commands to
- * a drive.
- */
-static ide_startstop_t ata_special(struct ata_device *drive)
-{
-	unsigned char special_cmd = drive->special_cmd;
-
-#ifdef DEBUG
-	printk("%s: ata_special: 0x%02x\n", drive->name, special_cmd);
-#endif
-	if (special_cmd & ATA_SPECIAL_TUNE) {
-		drive->special_cmd &= ~ATA_SPECIAL_TUNE;
-		if (drive->channel->tuneproc != NULL)
-			drive->channel->tuneproc(drive, drive->tune_req);
-	} else if (drive->driver != NULL) {
-		if (ata_ops(drive)->special)
-			return ata_ops(drive)->special(drive);
-		else {
-			drive->special_cmd = 0;
-			drive->mult_req = 0;
-
-			return ide_stopped;
-		}
-	} else if (special_cmd) {
-		printk("%s: bad special flag: 0x%02x\n", drive->name, special_cmd);
-		drive->special_cmd = 0;
-	}
-
-	return ide_stopped;
-}
-
 extern struct block_device_operations ide_fops[];
 
 /*
@@ -460,24 +424,24 @@
  */
 static ide_startstop_t atapi_reset_pollfunc(struct ata_device *drive, struct request *__rq)
 {
-	ide_hwgroup_t *hwgroup = HWGROUP(drive);
-	byte stat;
+	struct ata_channel *ch = drive->channel;
+	u8 stat;
 
-	SELECT_DRIVE(drive->channel,drive);
+	SELECT_DRIVE(ch,drive);
 	udelay (10);
 
 	if (OK_STAT(stat=GET_STAT(), 0, BUSY_STAT)) {
 		printk("%s: ATAPI reset complete\n", drive->name);
 	} else {
-		if (time_before(jiffies, hwgroup->poll_timeout)) {
+		if (time_before(jiffies, ch->poll_timeout)) {
 			ide_set_handler (drive, atapi_reset_pollfunc, HZ/20, NULL);
 			return ide_started;	/* continue polling */
 		}
-		hwgroup->poll_timeout = 0;	/* end of polling */
+		ch->poll_timeout = 0;	/* end of polling */
 		printk("%s: ATAPI reset timed-out, status=0x%02x\n", drive->name, stat);
 		return do_reset1 (drive, 1);	/* do it the old fashioned way */
 	}
-	hwgroup->poll_timeout = 0;	/* done polling */
+	ch->poll_timeout = 0;	/* done polling */
 
 	return ide_stopped;
 }
@@ -489,19 +453,18 @@
  */
 static ide_startstop_t reset_pollfunc(struct ata_device *drive, struct request *__rq)
 {
-	ide_hwgroup_t *hwgroup = HWGROUP(drive);
-	struct ata_channel *hwif = drive->channel;
+	struct ata_channel *ch = drive->channel;
 	u8 stat;
 
 	if (!OK_STAT(stat=GET_STAT(), 0, BUSY_STAT)) {
-		if (time_before(jiffies, hwgroup->poll_timeout)) {
+		if (time_before(jiffies, ch->poll_timeout)) {
 			ide_set_handler(drive, reset_pollfunc, HZ/20, NULL);
 			return ide_started;	/* continue polling */
 		}
-		printk("%s: reset timed-out, status=0x%02x\n", hwif->name, stat);
+		printk("%s: reset timed-out, status=0x%02x\n", ch->name, stat);
 		drive->failures++;
 	} else  {
-		printk("%s: reset: ", hwif->name);
+		printk("%s: reset: ", ch->name);
 		if ((stat = GET_ERR()) == 1) {
 			printk("success\n");
 			drive->failures = 0;
@@ -531,7 +494,8 @@
 			drive->failures++;
 		}
 	}
-	hwgroup->poll_timeout = 0;	/* done polling */
+	ch->poll_timeout = 0;	/* done polling */
+
 	return ide_stopped;
 }
 
@@ -555,21 +519,21 @@
 {
 	unsigned int unit;
 	unsigned long flags;
-	struct ata_channel *hwif = drive->channel;
-	ide_hwgroup_t *hwgroup = HWGROUP(drive);
+	struct ata_channel *ch = drive->channel;
 
 	__save_flags(flags);	/* local CPU only */
 	__cli();		/* local CPU only */
 
 	/* For an ATAPI device, first try an ATAPI SRST. */
 	if (drive->type != ATA_DISK && !do_not_try_atapi) {
-		ata_pre_reset(drive);
-		SELECT_DRIVE(hwif,drive);
+		check_crc_errors(drive);
+		SELECT_DRIVE(ch, drive);
 		udelay (20);
 		OUT_BYTE(WIN_SRST, IDE_COMMAND_REG);
-		hwgroup->poll_timeout = jiffies + WAIT_WORSTCASE;
+		ch->poll_timeout = jiffies + WAIT_WORSTCASE;
 		ide_set_handler(drive, atapi_reset_pollfunc, HZ/20, NULL);
 		__restore_flags(flags);	/* local CPU only */
+
 		return ide_started;
 	}
 
@@ -578,11 +542,12 @@
 	 * for any of the drives on this interface.
 	 */
 	for (unit = 0; unit < MAX_DRIVES; ++unit)
-		ata_pre_reset(&hwif->drives[unit]);
+		check_crc_errors(&ch->drives[unit]);
 
 #if OK_TO_RESET_CONTROLLER
 	if (!IDE_CONTROL_REG) {
 		__restore_flags(flags);
+
 		return ide_stopped;
 	}
 	/*
@@ -601,7 +566,7 @@
 		OUT_BYTE(drive->ctl|2,IDE_CONTROL_REG);	/* clear SRST, leave nIEN */
 	}
 	udelay(10);			/* more than enough time */
-	hwgroup->poll_timeout = jiffies + WAIT_WORSTCASE;
+	ch->poll_timeout = jiffies + WAIT_WORSTCASE;
 	ide_set_handler(drive, reset_pollfunc, HZ/20, NULL);
 
 	/*
@@ -609,9 +574,10 @@
 	 * state when the disks are reset this way. At least, the Winbond
 	 * 553 documentation says that
 	 */
-	if (hwif->resetproc != NULL)
-		hwif->resetproc(drive);
+	if (ch->resetproc != NULL)
+		ch->resetproc(drive);
 
+	/* FIXME: we should handle mulit mode setting here as well ! */
 #endif
 
 	__restore_flags (flags);	/* local CPU only */
@@ -789,6 +755,36 @@
 	}
 }
 
+#ifdef CONFIG_BLK_DEV_PDC4030
+# define IS_PDC4030_DRIVE (drive->channel->chipset == ide_pdc4030)
+#else
+# define IS_PDC4030_DRIVE (0)	/* auto-NULLs out pdc4030 code */
+#endif
+
+/*
+ * We are still on the old request path here so issuing the recalibrate command
+ * directly should just work.
+ */
+static int do_recalibrate(struct ata_device *drive)
+{
+	printk(KERN_INFO "%s: recalibrating!\n", drive->name);
+
+	if (drive->type != ATA_DISK)
+		return ide_stopped;
+
+	if (!IS_PDC4030_DRIVE) {
+		struct ata_taskfile args;
+
+		memset(&args, 0, sizeof(args));
+		args.taskfile.sector_count = drive->sect;
+		args.taskfile.command = WIN_RESTORE;
+		args.handler = recal_intr;
+		ata_taskfile(drive, &args, NULL);
+	}
+
+	return IS_PDC4030_DRIVE ? ide_stopped : ide_started;
+}
+
 /*
  * Take action based on the error returned by the drive.
  */
@@ -835,13 +831,11 @@
 		else
 			ide_end_request(drive, rq, 0);
 	} else {
-		if ((rq->errors & ERROR_RESET) == ERROR_RESET) {
-			++rq->errors;
+		++rq->errors;
+		if ((rq->errors & ERROR_RESET) == ERROR_RESET)
 			return do_reset1(drive, 0);
-		}
 		if ((rq->errors & ERROR_RECAL) == ERROR_RECAL)
-			drive->special_cmd |= ATA_SPECIAL_RECALIBRATE;
-		++rq->errors;
+			return do_recalibrate(drive);
 	}
 	return ide_stopped;
 }
@@ -960,7 +954,7 @@
 		goto kill_rq;
 	}
 
-	block    = rq->sector;
+	block = rq->sector;
 
 	/* Strange disk manager remap.
 	 */
@@ -991,14 +985,6 @@
 		}
 	}
 
-	/* FIXME: We can see nicely here that all commands should be submitted
-	 * through the request queue and that the special field in drive should
-	 * go as soon as possible!
-	 */
-
-	if (drive->special_cmd)
-		return ata_special(drive);
-
 	/* This issues a special drive command, usually initiated by ioctl()
 	 * from the external hdparm program.
 	 */
@@ -1011,7 +997,7 @@
 		ata_taskfile(drive, args, NULL);
 
 		if (((args->command_type == IDE_DRIVE_TASK_RAW_WRITE) ||
-					(args->command_type == IDE_DRIVE_TASK_OUT)) &&
+		     (args->command_type == IDE_DRIVE_TASK_OUT)) &&
 				args->prehandler && args->handler)
 			return args->prehandler(drive, rq);
 
@@ -1053,6 +1039,7 @@
 			return ata_ops(drive)->do_request(drive, rq, block);
 		else {
 			ide_end_request(drive, rq, 0);
+
 			return ide_stopped;
 		}
 	}
@@ -1499,7 +1486,7 @@
 			disable_irq(ch->irq);	/* disable_irq_nosync ?? */
 #endif
 			__cli();	/* local CPU only, as if we were handling an interrupt */
-			if (hwgroup->poll_timeout != 0) {
+			if (ch->poll_timeout != 0) {
 				startstop = handler(drive, ch->hwgroup->rq);
 			} else if (drive_is_ready(drive)) {
 				if (drive->waiting_for_dma)
@@ -1598,7 +1585,7 @@
 	if (!ide_ack_intr(ch))
 		goto out_lock;
 
-	if (handler == NULL || hwgroup->poll_timeout != 0) {
+	if (handler == NULL || ch->poll_timeout != 0) {
 #if 0
 		printk(KERN_INFO "ide: unexpected interrupt %d %d\n", ch->unit, irq);
 #endif
@@ -2327,23 +2314,24 @@
 int ide_spin_wait_hwgroup(struct ata_device *drive)
 {
 	ide_hwgroup_t *hwgroup = HWGROUP(drive);
-	unsigned long timeout = jiffies + (3 * HZ);
+
+	/* FIXME: Wait on a proper timer. Instead of playing games on the
+	 * spin_lock().
+	 */
+
+	unsigned long timeout = jiffies + (10 * HZ);
 
 	spin_lock_irq(&ide_lock);
 
 	while (test_bit(IDE_BUSY, &hwgroup->flags)) {
-		unsigned long lflags;
 		spin_unlock_irq(&ide_lock);
-		__save_flags(lflags);	/* local CPU only */
-		__sti();		/* local CPU only; needed for jiffies */
-		if (0 < (signed long)(jiffies - timeout)) {
-			__restore_flags(lflags);	/* local CPU only */
+		if (time_after(jiffies, timeout)) {
 			printk("%s: channel busy\n", drive->name);
 			return -EBUSY;
 		}
-		__restore_flags(lflags);	/* local CPU only */
 		spin_lock_irq(&ide_lock);
 	}
+
 	return 0;
 }
 
@@ -2411,18 +2399,17 @@
 
 static int set_pio_mode(struct ata_device *drive, int arg)
 {
-	struct request rq;
-
 	if (!drive->channel->tuneproc)
 		return -ENOSYS;
 
-	if (drive->special_cmd & ATA_SPECIAL_TUNE)
+	/* FIXME: This is very much the same kind of problem as we have with
+	 * set_mutlmode() see for a edscription there.
+	 */
+	if (HWGROUP(drive)->handler)
 		return -EBUSY;
 
-	ide_init_drive_cmd(&rq);
-	drive->tune_req = (u8) arg;
-	drive->special_cmd |= ATA_SPECIAL_TUNE;
-	ide_do_drive_cmd(drive, &rq, ide_wait);
+	if (drive->channel->tuneproc != NULL)
+		drive->channel->tuneproc(drive, (u8) arg);
 
 	return 0;
 }
diff -urN linux-2.5.14/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
--- linux-2.5.14/drivers/ide/ide-disk.c	2002-05-07 02:36:37.000000000 +0200
+++ linux/drivers/ide/ide-disk.c	2002-05-07 02:01:48.000000000 +0200
@@ -34,9 +34,9 @@
 #include <asm/io.h>
 
 #ifdef CONFIG_BLK_DEV_PDC4030
-#define IS_PDC4030_DRIVE (drive->channel->chipset == ide_pdc4030)
+# define IS_PDC4030_DRIVE (drive->channel->chipset == ide_pdc4030)
 #else
-#define IS_PDC4030_DRIVE (0)	/* auto-NULLs out pdc4030 code */
+# define IS_PDC4030_DRIVE (0)	/* auto-NULLs out pdc4030 code */
 #endif
 
 /*
@@ -304,9 +304,9 @@
 	}
 
 	if (IS_PDC4030_DRIVE) {
-		extern ide_startstop_t promise_rw_disk(struct ata_device *, struct request *, unsigned long);
+		extern ide_startstop_t promise_do_request(struct ata_device *, struct request *, sector_t);
 
-		return promise_rw_disk(drive, rq, block);
+		return promise_do_request(drive, rq, block);
 	}
 
 	/*
@@ -364,7 +364,7 @@
 		 * point.
 		 */
 
-		if (drive->doorlocking && ide_raw_taskfile(drive, &args, NULL))
+		if (drive->doorlocking && ide_raw_taskfile(drive, &args))
 			drive->doorlocking = 0;
 	}
 	return 0;
@@ -383,10 +383,10 @@
 
 	ide_cmd_type_parser(&args);
 
-	return ide_raw_taskfile(drive, &args, NULL);
+	return ide_raw_taskfile(drive, &args);
 }
 
-static void idedisk_release (struct inode *inode, struct file *filp, struct ata_device *drive)
+static void idedisk_release(struct inode *inode, struct file *filp, struct ata_device *drive)
 {
 	if (drive->removable && !drive->usage) {
 		struct ata_taskfile args;
@@ -398,7 +398,7 @@
 		ide_cmd_type_parser(&args);
 
 		if (drive->doorlocking &&
-		    ide_raw_taskfile(drive, &args, NULL))
+		    ide_raw_taskfile(drive, &args))
 			drive->doorlocking = 0;
 	}
 	if ((drive->id->cfs_enable_2 & 0x3000) && drive->wcache)
@@ -419,75 +419,6 @@
 	return drive->capacity - drive->sect0;
 }
 
-static ide_startstop_t idedisk_special(struct ata_device *drive)
-{
-	unsigned char special_cmd = drive->special_cmd;
-
-	if (special_cmd & ATA_SPECIAL_GEOMETRY) {
-		struct ata_taskfile args;
-
-		drive->special_cmd &= ~ATA_SPECIAL_GEOMETRY;
-
-		memset(&args, 0, sizeof(args));
-		args.taskfile.sector_number	= drive->sect;
-		args.taskfile.low_cylinder	= drive->cyl;
-		args.taskfile.high_cylinder	= drive->cyl>>8;
-		args.taskfile.device_head	= ((drive->head-1)|drive->select.all)&0xBF;
-		if (!IS_PDC4030_DRIVE) {
-			args.taskfile.sector_count = drive->sect;
-			args.taskfile.command = WIN_SPECIFY;
-			args.handler = set_geometry_intr;;
-		}
-		ata_taskfile(drive, &args, NULL);
-	} else if (special_cmd & ATA_SPECIAL_RECALIBRATE) {
-		drive->special_cmd &= ~ATA_SPECIAL_RECALIBRATE;
-
-		if (!IS_PDC4030_DRIVE) {
-			struct ata_taskfile args;
-
-			memset(&args, 0, sizeof(args));
-			args.taskfile.sector_count = drive->sect;
-			args.taskfile.command = WIN_RESTORE;
-			args.handler = recal_intr;
-			ata_taskfile(drive, &args, NULL);
-		}
-	} else if (special_cmd & ATA_SPECIAL_MMODE) {
-		drive->special_cmd &= ~ATA_SPECIAL_MMODE;
-		if (drive->id && drive->mult_req > drive->id->max_multsect)
-			drive->mult_req = drive->id->max_multsect;
-		if (!IS_PDC4030_DRIVE) {
-			struct ata_taskfile args;
-
-			memset(&args, 0, sizeof(args));
-			args.taskfile.sector_count = drive->mult_req;
-			args.taskfile.command = WIN_SETMULT;
-			args.handler = set_multmode_intr;
-
-			ata_taskfile(drive, &args, NULL);
-		}
-	} else if (special_cmd) {
-		drive->special_cmd = 0;
-
-		printk(KERN_ERR "%s: bad special flag: 0x%02x\n", drive->name, special_cmd);
-		return ide_stopped;
-	}
-	return IS_PDC4030_DRIVE ? ide_stopped : ide_started;
-}
-
-static void idedisk_pre_reset(struct ata_device *drive)
-{
-	int legacy = (drive->id->cfs_enable_2 & 0x0400) ? 0 : 1;
-
-	if (legacy)
-		drive->special_cmd = (ATA_SPECIAL_GEOMETRY | ATA_SPECIAL_RECALIBRATE);
-	else
-		drive->special_cmd = 0;
-	if (OK_TO_RESET_CONTROLLER)
-		drive->mult_count = 0;
-	if (drive->mult_req != drive->mult_count)
-		drive->special_cmd |= ATA_SPECIAL_MMODE;
-}
-
 #ifdef CONFIG_PROC_FS
 
 #ifdef CONFIG_BLK_DEV_IDE_TCQ
@@ -556,28 +487,58 @@
  */
 static int set_multcount(struct ata_device *drive, int arg)
 {
-	struct request rq;
+	struct ata_taskfile args;
+
+	/* Setting multi mode count on this channel type is not supported/not
+	 * handled.
+	 */
+	if (IS_PDC4030_DRIVE)
+		return -EIO;
+
+	/* Hugh, we still didn't detect the devices capabilities.
+	 */
+	if (!drive->id)
+		return -EIO;
 
-	if (drive->special_cmd & ATA_SPECIAL_MMODE)
+	/* FIXME: Hmm... just bailing out my be problematic, since there *is*
+	 * activity during boot. For now the same problem persists in
+	 * set_pio_mode() we will have to do something about it soon.
+	 */
+	if (HWGROUP(drive)->handler)
 		return -EBUSY;
 
-	ide_init_drive_cmd(&rq);
+	if (arg > drive->id->max_multsect)
+		arg = drive->id->max_multsect;
 
-	drive->mult_req = arg;
-	drive->special_cmd |= ATA_SPECIAL_MMODE;
+	memset(&args, 0, sizeof(args));
+	args.taskfile.sector_count = arg;
+	args.taskfile.command	= WIN_SETMULT;
+	ide_cmd_type_parser(&args);
 
-	ide_do_drive_cmd(drive, &rq, ide_wait);
+	if (!ide_raw_taskfile(drive, &args)) {
+		/* all went well track this setting as valid */
+		drive->mult_count = arg;
+
+		return 0;
+	} else
+		drive->mult_count = 0; /* reset */
 
-	return (drive->mult_count == arg) ? 0 : -EIO;
+	return -EIO;
 }
 
 static int set_nowerr(struct ata_device *drive, int arg)
 {
-	if (ide_spin_wait_hwgroup(drive))
+	if (HWGROUP(drive)->handler)
 		return -EBUSY;
+
 	drive->nowerr = arg;
 	drive->bad_wstat = arg ? BAD_R_STAT : BAD_W_STAT;
+
+	/* FIXME: I'm less then sure that we are under the global request lock here!
+	 */
+#if 0
 	spin_unlock_irq(&ide_lock);
+#endif
 
 	return 0;
 }
@@ -593,7 +554,7 @@
 	args.taskfile.feature	= (arg) ? SETFEATURES_EN_WCACHE : SETFEATURES_DIS_WCACHE;
 	args.taskfile.command	= WIN_SETFEATURES;
 	ide_cmd_type_parser(&args);
-	ide_raw_taskfile(drive, &args, NULL);
+	ide_raw_taskfile(drive, &args);
 
 	drive->wcache = arg;
 
@@ -608,7 +569,7 @@
 	args.taskfile.command = WIN_STANDBYNOW1;
 	ide_cmd_type_parser(&args);
 
-	return ide_raw_taskfile(drive, &args, NULL);
+	return ide_raw_taskfile(drive, &args);
 }
 
 static int set_acoustic(struct ata_device *drive, int arg)
@@ -620,7 +581,7 @@
 	args.taskfile.sector_count = arg;
 	args.taskfile.command = WIN_SETFEATURES;
 	ide_cmd_type_parser(&args);
-	ide_raw_taskfile(drive, &args, NULL);
+	ide_raw_taskfile(drive, &args);
 
 	drive->acoustic = arg;
 
@@ -673,17 +634,11 @@
 {
 	struct hd_driveid *id = drive->id;
 
-	ide_add_setting(drive,	"bios_cyl",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	65535,				1,	1,	&drive->bios_cyl,		NULL);
-	ide_add_setting(drive,	"bios_head",		SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	255,				1,	1,	&drive->bios_head,		NULL);
-	ide_add_setting(drive,	"bios_sect",		SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	63,				1,	1,	&drive->bios_sect,		NULL);
 	ide_add_setting(drive,	"address",		SETTING_RW,					HDIO_GET_ADDRESS,	HDIO_SET_ADDRESS,	TYPE_INTA,	0,	2,				1,	1,	&drive->addressing,	set_lba_addressing);
 	ide_add_setting(drive,	"multcount",		id ? SETTING_RW : SETTING_READ,			HDIO_GET_MULTCOUNT,	HDIO_SET_MULTCOUNT,	TYPE_BYTE,	0,	id ? id->max_multsect : 0,	1,	1,	&drive->mult_count,		set_multcount);
 	ide_add_setting(drive,	"nowerr",		SETTING_RW,					HDIO_GET_NOWERR,	HDIO_SET_NOWERR,	TYPE_BYTE,	0,	1,				1,	1,	&drive->nowerr,			set_nowerr);
-	ide_add_setting(drive,	"lun",			SETTING_RW,					-1,			-1,			TYPE_INT,	0,	7,				1,	1,	&drive->lun,			NULL);
 	ide_add_setting(drive,	"wcache",		SETTING_RW,					HDIO_GET_WCACHE,	HDIO_SET_WCACHE,	TYPE_BYTE,	0,	1,				1,	1,	&drive->wcache,			write_cache);
 	ide_add_setting(drive,	"acoustic",		SETTING_RW,					HDIO_GET_ACOUSTIC,	HDIO_SET_ACOUSTIC,	TYPE_BYTE,	0,	254,				1,	1,	&drive->acoustic,		set_acoustic);
-	ide_add_setting(drive,	"failures",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	65535,				1,	1,	&drive->failures,		NULL);
-	ide_add_setting(drive,	"max_failures",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	65535,				1,	1,	&drive->max_failures,		NULL);
 #ifdef CONFIG_BLK_DEV_IDE_TCQ
 	ide_add_setting(drive,	"using_tcq",		SETTING_RW,					HDIO_GET_QDMA,		HDIO_SET_QDMA,		TYPE_BYTE,	0,	IDE_MAX_TAG,			1,		1,		&drive->using_tcq,		set_using_tcq);
 #endif
@@ -761,7 +716,7 @@
 	args.handler = task_no_data_intr;
 
 	/* submit command request */
-	ide_raw_taskfile(drive, &args, NULL);
+	ide_raw_taskfile(drive, &args);
 
 	/* if OK, compute maximum address value */
 	if ((args.taskfile.command & 0x01) == 0) {
@@ -789,7 +744,7 @@
 	args.handler = task_no_data_intr;
 
         /* submit command request */
-        ide_raw_taskfile(drive, &args, NULL);
+        ide_raw_taskfile(drive, &args);
 
 	/* if OK, compute maximum address value */
 	if ((args.taskfile.command & 0x01) == 0) {
@@ -829,7 +784,7 @@
 	args.taskfile.command = WIN_SET_MAX;
 	args.handler = task_no_data_intr;
 	/* submit command request */
-	ide_raw_taskfile(drive, &args, NULL);
+	ide_raw_taskfile(drive, &args);
 	/* if OK, read new maximum address value */
 	if ((args.taskfile.command & 0x01) == 0) {
 		addr_set = ((args.taskfile.device_head & 0x0f) << 24)
@@ -865,7 +820,7 @@
 
         args.handler = task_no_data_intr;
 	/* submit command request */
-	ide_raw_taskfile(drive, &args, NULL);
+	ide_raw_taskfile(drive, &args);
 	/* if OK, compute maximum address value */
 	if ((args.taskfile.command & 0x01) == 0) {
 		u32 high = (args.hobfile.high_cylinder << 16) |
@@ -1078,7 +1033,13 @@
 	printk("\n");
 
 	drive->mult_count = 0;
+#if 0
 	if (id->max_multsect) {
+
+		/* FIXME: reenable this again after making it to use
+		 * the same code path as the ioctl stuff.
+		 */
+
 #ifdef CONFIG_IDEDISK_MULTI_MODE
 		id->multsect = ((id->max_multsect/2) > 1) ? id->max_multsect : 0;
 		id->multsect_valid = id->multsect ? 1 : 0;
@@ -1094,6 +1055,7 @@
 			drive->special_cmd |= ATA_SPECIAL_MMODE;
 #endif
 	}
+#endif
 
 	/* FIXME: Nowadays there are many chipsets out there which *require* 32
 	 * bit IO. Those will most propably not work properly with drives not
@@ -1136,9 +1098,7 @@
 	release:		idedisk_release,
 	check_media_change:	idedisk_check_media_change,
 	revalidate:		NULL, /* use default method */
-	pre_reset:		idedisk_pre_reset,
 	capacity:		idedisk_capacity,
-	special:		idedisk_special,
 	proc:			idedisk_proc
 };
 
diff -urN linux-2.5.14/drivers/ide/ide-tape.c linux/drivers/ide/ide-tape.c
--- linux-2.5.14/drivers/ide/ide-tape.c	2002-05-07 02:36:37.000000000 +0200
+++ linux/drivers/ide/ide-tape.c	2002-05-07 01:23:42.000000000 +0200
@@ -4273,16 +4273,6 @@
 }
 
 /*
- *	idetape_pre_reset is called before an ATAPI/ATA software reset.
- */
-static void idetape_pre_reset (ide_drive_t *drive)
-{
-	idetape_tape_t *tape = drive->driver_data;
-	if (tape != NULL)
-		set_bit (IDETAPE_IGNORE_DSC, &tape->flags);
-}
-
-/*
  *	Character device interface functions
  */
 static ide_drive_t *get_drive_ptr (kdev_t i_rdev)
@@ -6164,8 +6154,6 @@
 	release:		idetape_blkdev_release,
 	check_media_change:	NULL,
 	revalidate:		idetape_revalidate,
-	pre_reset:		idetape_pre_reset,
-	capacity:		NULL,
 	proc:			idetape_proc
 };
 
diff -urN linux-2.5.14/drivers/ide/ide-taskfile.c linux/drivers/ide/ide-taskfile.c
--- linux-2.5.14/drivers/ide/ide-taskfile.c	2002-05-07 02:36:37.000000000 +0200
+++ linux/drivers/ide/ide-taskfile.c	2002-05-07 02:30:11.000000000 +0200
@@ -489,40 +489,6 @@
 }
 
 /*
- * This is invoked on completion of a WIN_SETMULT cmd.
- */
-ide_startstop_t set_multmode_intr(struct ata_device *drive, struct request *__rq)
-{
-	u8 stat;
-
-	if (OK_STAT(stat = GET_STAT(),READY_STAT,BAD_STAT)) {
-		drive->mult_count = drive->mult_req;
-	} else {
-		drive->mult_req = drive->mult_count = 0;
-		drive->special_cmd |= ATA_SPECIAL_RECALIBRATE;
-		ide_dump_status(drive, "set_multmode", stat);
-	}
-	return ide_stopped;
-}
-
-/*
- * This is invoked on completion of a WIN_SPECIFY cmd.
- */
-ide_startstop_t set_geometry_intr(struct ata_device *drive, struct request *__rq)
-{
-	u8 stat;
-
-	if (OK_STAT(stat=GET_STAT(),READY_STAT,BAD_STAT))
-		return ide_stopped;
-
-	if (stat & (ERR_STAT|DRQ_STAT))
-		return ide_error(drive, "set_geometry_intr", stat);
-
-	ide_set_handler(drive, set_geometry_intr, WAIT_CMD, NULL);
-	return ide_started;
-}
-
-/*
  * This is invoked on completion of a WIN_RESTORE (recalibrate) cmd.
  */
 ide_startstop_t recal_intr(struct ata_device *drive, struct request *__rq)
@@ -729,11 +695,11 @@
 			args->command_type = IDE_DRIVE_TASK_IN;
 			return;
 
+		case CFA_WRITE_SECT_WO_ERASE:
 		case WIN_WRITE:
 		case WIN_WRITE_EXT:
 		case WIN_WRITE_VERIFY:
 		case WIN_WRITE_BUFFER:
-		case CFA_WRITE_SECT_WO_ERASE:
 		case WIN_DOWNLOAD_MICROCODE:
 			args->prehandler = pre_task_out_intr;
 			args->handler = task_out_intr;
@@ -832,7 +798,7 @@
 			}
 
 		case WIN_SPECIFY:
-			args->handler = set_geometry_intr;
+			args->handler = task_no_data_intr;
 			args->command_type = IDE_DRIVE_TASK_NO_DATA;
 			return;
 
@@ -874,7 +840,7 @@
 			return;
 
 		case WIN_SETMULT:
-			args->handler = set_multmode_intr;
+			args->handler = task_no_data_intr;
 			args->command_type = IDE_DRIVE_TASK_NO_DATA;
 			return;
 
@@ -894,19 +860,19 @@
 	}
 }
 
-int ide_raw_taskfile(struct ata_device *drive, struct ata_taskfile *args, byte *buf)
+int ide_raw_taskfile(struct ata_device *drive, struct ata_taskfile *args)
 {
 	struct request rq;
 
 	memset(&rq, 0, sizeof(rq));
 	rq.flags = REQ_DRIVE_ACB;
-	rq.buffer = buf;
 
+#if 0
 	if (args->command_type != IDE_DRIVE_TASK_NO_DATA)
 		rq.current_nr_sectors = rq.nr_sectors
 			= (args->hobfile.sector_count << 8)
 			| args->taskfile.sector_count;
-
+#endif
 	rq.special = args;
 
 	return ide_do_drive_cmd(drive, &rq, ide_wait);
@@ -996,8 +962,6 @@
 EXPORT_SYMBOL(atapi_write);
 EXPORT_SYMBOL(ata_taskfile);
 EXPORT_SYMBOL(recal_intr);
-EXPORT_SYMBOL(set_geometry_intr);
-EXPORT_SYMBOL(set_multmode_intr);
 EXPORT_SYMBOL(task_no_data_intr);
 EXPORT_SYMBOL(ide_raw_taskfile);
 EXPORT_SYMBOL(ide_cmd_type_parser);
diff -urN linux-2.5.14/drivers/ide/pdc4030.c linux/drivers/ide/pdc4030.c
--- linux-2.5.14/drivers/ide/pdc4030.c	2002-05-06 05:37:57.000000000 +0200
+++ linux/drivers/ide/pdc4030.c	2002-05-06 19:55:23.000000000 +0200
@@ -39,6 +39,7 @@
  *  Version 0.90	Transition to BETA code. No lost/unexpected interrupts
  *  Version 0.91	Bring in line with new bio code in 2.5.1
  *  Version 0.92	Update for IDE driver taskfile changes
+ *  Version 0.93	Sync with 2.5.10, minor taskfile changes
  */
 
 /*
@@ -380,6 +381,7 @@
 }
 
 /*
+ * promise_complete_pollfunc()
  * This is the polling function for waiting (nicely!) until drive stops
  * being busy. It is invoked at the end of a write, after the previous poll
  * has finished.
@@ -388,20 +390,20 @@
  */
 static ide_startstop_t promise_complete_pollfunc(struct ata_device *drive, struct request *rq)
 {
-	ide_hwgroup_t *hwgroup = HWGROUP(drive);
+	struct ata_channel *ch = drive->channel;
 
 	if (GET_STAT() & BUSY_STAT) {
-		if (time_before(jiffies, hwgroup->poll_timeout)) {
+		if (time_before(jiffies, ch->poll_timeout)) {
 			ide_set_handler(drive, promise_complete_pollfunc, HZ/100, NULL);
 			return ide_started; /* continue polling... */
 		}
-		hwgroup->poll_timeout = 0;
+		ch->poll_timeout = 0;
 		printk(KERN_ERR "%s: completion timeout - still busy!\n",
 		       drive->name);
 		return ide_error(drive, "busy timeout", GET_STAT());
 	}
 
-	hwgroup->poll_timeout = 0;
+	ch->poll_timeout = 0;
 #ifdef DEBUG_WRITE
 	printk(KERN_DEBUG "%s: Write complete - end_request\n", drive->name);
 #endif
@@ -432,7 +434,7 @@
 			nsect = mcount;
 		mcount -= nsect;
 
-		buffer = bio_kmap_irq(rq->bio, flags) + ide_rq_offset(rq);
+		buffer = bio_kmap_irq(rq->bio, &flags) + ide_rq_offset(rq);
 		rq->sector += nsect;
 		rq->nr_sectors -= nsect;
 		rq->current_nr_sectors -= nsect;
@@ -467,23 +469,23 @@
  */
 static ide_startstop_t promise_write_pollfunc(struct ata_device *drive, struct request *rq)
 {
-	ide_hwgroup_t *hwgroup = HWGROUP(drive);
+	struct ata_channel *ch = drive->channel;
 
 	if (IN_BYTE(IDE_NSECTOR_REG) != 0) {
-		if (time_before(jiffies, hwgroup->poll_timeout)) {
+		if (time_before(jiffies, ch->poll_timeout)) {
 			ide_set_handler(drive, promise_write_pollfunc, HZ/100, NULL);
 			return ide_started; /* continue polling... */
 		}
-		hwgroup->poll_timeout = 0;
+		ch->poll_timeout = 0;
 		printk(KERN_ERR "%s: write timed-out!\n",drive->name);
-		return ide_error (drive, "write timeout", GET_STAT());
+		return ide_error(drive, "write timeout", GET_STAT());
 	}
 
 	/*
 	 * Now write out last 4 sectors and poll for not BUSY
 	 */
 	promise_multwrite(drive, rq, 4);
-	hwgroup->poll_timeout = jiffies + WAIT_WORSTCASE;
+	ch->poll_timeout = jiffies + WAIT_WORSTCASE;
 	ide_set_handler(drive, promise_complete_pollfunc, HZ/100, NULL);
 #ifdef DEBUG_WRITE
 	printk(KERN_DEBUG "%s: Done last 4 sectors - status = %02x\n",
@@ -501,7 +503,7 @@
  */
 static ide_startstop_t promise_write(struct ata_device *drive, struct request *rq)
 {
-	ide_hwgroup_t *hwgroup = HWGROUP(drive);
+	struct ata_channel *ch = drive->channel;
 
 #ifdef DEBUG_WRITE
 	printk(KERN_DEBUG "%s: promise_write: sectors(%ld-%ld), "
@@ -516,7 +518,7 @@
 	if (rq->nr_sectors > 4) {
 		if (promise_multwrite(drive, rq, rq->nr_sectors - 4))
 			return ide_stopped;
-		hwgroup->poll_timeout = jiffies + WAIT_WORSTCASE;
+		ch->poll_timeout = jiffies + WAIT_WORSTCASE;
 		ide_set_handler(drive, promise_write_pollfunc, HZ/100, NULL);
 		return ide_started;
 	} else {
@@ -526,7 +528,7 @@
 	 */
 		if (promise_multwrite(drive, rq, rq->nr_sectors))
 			return ide_stopped;
-		hwgroup->poll_timeout = jiffies + WAIT_WORSTCASE;
+		ch->poll_timeout = jiffies + WAIT_WORSTCASE;
 		ide_set_handler(drive, promise_complete_pollfunc, HZ/100, NULL);
 #ifdef DEBUG_WRITE
 		printk(KERN_DEBUG "%s: promise_write: <= 4 sectors, "
@@ -537,13 +539,13 @@
 }
 
 /*
- * do_pdc4030_io() is called from do_rw_disk, having had the block number
- * already set up. It issues a READ or WRITE command to the Promise
+ * do_pdc4030_io() is called from promise_do_request, having had the block
+ * number already set up. It issues a READ or WRITE command to the Promise
  * controller, assuming LBA has been used to set up the block number.
  */
-ide_startstop_t do_pdc4030_io(struct ata_device *drive, struct ata_taskfile *task, struct request *rq)
+ide_startstop_t do_pdc4030_io(struct ata_device *drive, struct ata_taskfile *args, struct request *rq)
 {
-	struct hd_drive_task_hdr *taskfile = &task->taskfile;
+	struct hd_drive_task_hdr *taskfile = &(args->taskfile);
 	unsigned long timeout;
 	byte stat;
 
@@ -628,7 +630,7 @@
 	}
 }
 
-ide_startstop_t promise_rw_disk(struct ata_device *drive, struct request *rq, sector_t block)
+ide_startstop_t promise_do_request(struct ata_device *drive, struct request *rq, sector_t block)
 {
 	struct ata_taskfile args;
 
@@ -647,12 +649,12 @@
 	args.taskfile.device_head	= ((block>>8)&0x0f)|drive->select.all;
 	args.taskfile.command		= (rq_data_dir(rq)==READ)?PROMISE_READ:PROMISE_WRITE;
 
-	ide_cmd_type_parser(&args);
-	/* We don't use the generic inerrupt handlers here? */
-	args.prehandler		= NULL;
+	/* We can't call ide_cmd_type_parser here, since it won't understand
+	   our command, but that doesn't matter, since we don't use the
+	   generic interrupt handlers either. Setup the bits of args that we
+	   will need. */
 	args.handler		= NULL;
 	rq->special		= &args;
 
 	return do_pdc4030_io(drive, &args, rq);
 }
-
diff -urN linux-2.5.14/drivers/ide/tcq.c linux/drivers/ide/tcq.c
--- linux-2.5.14/drivers/ide/tcq.c	2002-05-06 05:38:05.000000000 +0200
+++ linux/drivers/ide/tcq.c	2002-05-06 20:11:27.000000000 +0200
@@ -418,7 +418,7 @@
 	 * pass NOP with sub-code 0x01 to device, so the command will not
 	 * fail there
 	 */
-	ide_raw_taskfile(drive, &args, NULL);
+	ide_raw_taskfile(drive, &args);
 	if (args.taskfile.feature & ABRT_ERR)
 		return 1;
 
@@ -448,7 +448,7 @@
 	args.taskfile.command = WIN_SETFEATURES;
 	ide_cmd_type_parser(&args);
 
-	if (ide_raw_taskfile(drive, &args, NULL)) {
+	if (ide_raw_taskfile(drive, &args)) {
 		printk("%s: failed to enable write cache\n", drive->name);
 		return 1;
 	}
@@ -462,7 +462,7 @@
 	args.taskfile.command = WIN_SETFEATURES;
 	ide_cmd_type_parser(&args);
 
-	if (ide_raw_taskfile(drive, &args, NULL)) {
+	if (ide_raw_taskfile(drive, &args)) {
 		printk("%s: disabling release interrupt fail\n", drive->name);
 		return 1;
 	}
@@ -476,7 +476,7 @@
 	args.taskfile.command = WIN_SETFEATURES;
 	ide_cmd_type_parser(&args);
 
-	if (ide_raw_taskfile(drive, &args, NULL)) {
+	if (ide_raw_taskfile(drive, &args)) {
 		printk("%s: enabling service interrupt fail\n", drive->name);
 		return 1;
 	}
diff -urN linux-2.5.14/include/linux/ide.h linux/include/linux/ide.h
--- linux-2.5.14/include/linux/ide.h	2002-05-07 02:36:38.000000000 +0200
+++ linux/include/linux/ide.h	2002-05-07 02:30:15.000000000 +0200
@@ -47,7 +47,7 @@
 # define DISK_RECOVERY_TIME	0	/*  for hardware that needs it */
 #endif
 #ifndef OK_TO_RESET_CONTROLLER		/* 1 needed for good error recovery */
-# define OK_TO_RESET_CONTROLLER	1	/* 0 for use with AH2372A/B interface */
+# define OK_TO_RESET_CONTROLLER	0	/* 0 for use with AH2372A/B interface */
 #endif
 #ifndef FANCY_STATUS_DUMPS		/* 1 for human-readable drive errors */
 # define FANCY_STATUS_DUMPS	1	/* 0 to reduce kernel size */
@@ -327,19 +327,9 @@
 	 */
 	request_queue_t	queue;	/* per device request queue */
 
-
 	unsigned long sleep;	/* sleep until this time */
 
-	/* Flags requesting/indicating one of the following special commands
-	 * executed on the request queue.
-	 */
-#define ATA_SPECIAL_GEOMETRY		0x01
-#define ATA_SPECIAL_RECALIBRATE		0x02
-#define ATA_SPECIAL_MMODE		0x04
-#define ATA_SPECIAL_TUNE		0x08
-	unsigned char special_cmd;
-	u8 mult_req;			/* requested multiple sector setting */
-	u8 tune_req;			/* requested drive tuning setting */
+	u8 XXX_tune_req;			/* requested drive tuning setting */
 
 	byte     using_dma;		/* disk is using dma for read/write */
 	byte	 using_tcq;		/* disk is using queueing */
@@ -409,6 +399,7 @@
 	unsigned int	failures;	/* current failure count */
 	unsigned int	max_failures;	/* maximum allowed failure count */
 	struct device	device;		/* global device tree handle */
+
 	/*
 	 * tcq statistics
 	 */
@@ -517,6 +508,8 @@
 	/* driver soft-power interface */
 	int (*busproc)(struct ata_device *, int);
 	byte		bus_state;	/* power state of the IDE bus */
+
+	unsigned long poll_timeout; /* timeout value during polled operations */
 };
 
 /*
@@ -565,17 +558,19 @@
 	return 1;
 }
 #else
-#define ata_pending_commands(drive)	(0)
-#define ata_can_queue(drive)		(1)
+# define ata_pending_commands(drive)	(0)
+# define ata_can_queue(drive)		(1)
 #endif
 
 typedef struct hwgroup_s {
+	/* FIXME: We should look for busy request queues instead of looking at
+	 * the !NULL state of this field.
+	 */
 	ide_startstop_t (*handler)(struct ata_device *, struct request *);	/* irq handler, if active */
 	unsigned long flags;		/* BUSY, SLEEPING */
 	struct ata_device *XXX_drive;	/* current drive */
 	struct request *rq;		/* current request */
 	struct timer_list timer;	/* failsafe timer */
-	unsigned long poll_timeout;	/* timeout value during long polls */
 	int (*expiry)(struct ata_device *, struct request *);	/* irq handler, if active */
 } ide_hwgroup_t;
 
@@ -675,9 +670,7 @@
 	int (*check_media_change)(struct ata_device *);
 	void (*revalidate)(struct ata_device *);
 
-	void (*pre_reset)(struct ata_device *);
 	sector_t (*capacity)(struct ata_device *);
-	ide_startstop_t	(*special)(struct ata_device *);
 
 	ide_proc_entry_t *proc;
 };
@@ -827,15 +820,13 @@
  */
 
 extern ide_startstop_t recal_intr(struct ata_device *, struct request *);
-extern ide_startstop_t set_geometry_intr(struct ata_device *, struct request *);
-extern ide_startstop_t set_multmode_intr(struct ata_device *, struct request *);
 extern ide_startstop_t task_no_data_intr(struct ata_device *, struct request *);
 
 
 /* This is setting up all fields in args, which depend upon the command type.
  */
 extern void ide_cmd_type_parser(struct ata_taskfile *args);
-extern int ide_raw_taskfile(struct ata_device *drive, struct ata_taskfile *cmd, byte *buf);
+extern int ide_raw_taskfile(struct ata_device *, struct ata_taskfile *);
 extern int ide_cmd_ioctl(struct ata_device *drive, unsigned long arg);
 
 void ide_delay_50ms(void);

Re: [PATCH] 2.5.14 IDE 56

[Padraig Brady]

Martin Dalecki wrote:
> Mon May  6 13:29:44 CEST 2002 ide-clean-56
> 

[snip]

> OK. After realizing the simple fact that quite a lot of low level 
> hardware manipulating ioctls may require assistance in usage from 
 > proper logic which is *very* unlikely to be implemented in a bash
 > (for me preferable still ksh) I have made my mind up.
> 
>     /proc/ide will be nuked.

Please consider this carefully, especially the read only bits.
One particular thing I use a lot is: /proc/ide/hda/capacity
Will there be another interface easily usable by scripts
to get this information?

Am I going to have to parse hdparm output?
....
  geometry     = 2434/255/63, sectors = 39102336, start = 0

Am I going to need hdparm on my embedded system?

Padraig.

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Padraig Brady napisa?:

> Am I going to have to parse hdparm output?
> ....
>  geometry     = 2434/255/63, sectors = 39102336, start = 0
> 
> Am I going to need hdparm on my embedded system?

Yes. Or just fsck hardcode the defaults.

Re: [PATCH] 2.5.14 IDE 56

[Padraig Brady]

Martin Dalecki wrote:
> Uz.ytkownik Padraig Brady napisa?:
> 
>> Am I going to have to parse hdparm output?
>> ....
>>  geometry     = 2434/255/63, sectors = 39102336, start = 0
>>
>> Am I going to need hdparm on my embedded system?
> 
> 
> Yes. Or just fsck hardcode the defaults.
> 

hardcode defaults?

Also are the following standard RH7.1 programs going to
need changing?

[padraig@pixelbeat padraig]$ find /sbin /usr/sbin /bin /usr/bin /lib 
/usr/lib /usr/bin/X11/ -xdev -perm +111 | xargs grep -l /proc/ide 
2>/dev/null
/sbin/mkinitrd
/sbin/fdisk
/sbin/sfdisk
/sbin/sndconfig
/usr/sbin/mouseconfig
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/updfstab
/usr/sbin/glidelink
/usr/sbin/sndconfig
/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/bin/X11/Xconfigurator

Padraig.

Re: [PATCH] 2.5.14 IDE 56

[Anton Altaparmakov]

At 14:15 07/05/02, Martin Dalecki wrote:
>Uz.ytkownik Padraig Brady napisa?:
>>Am I going to have to parse hdparm output?
>>....
>>  geometry     = 2434/255/63, sectors = 39102336, start = 0
>>Am I going to need hdparm on my embedded system?
>
>Yes. Or just fsck hardcode the defaults.

This is stupid! And if that isn't obvious to you, you should think a bit 
more carefully...

Linux's power is exactly that it can be used on anything from a wristwatch 
to a huge server and that it is flexible about everything. You are breaking 
this flexibility for no apparent reason. (I don't accept "I can't cope with 
this so I remove it." as a reason, sorry).

As the new IDE maintainer so far we have only seen you removing one feature 
after the other in the name of cleanup, without adequate or even any at 
all(!) replacements, renaming all functions to hell and back, and breaking 
the ide core here there and everywhere. All critical bug fixes seem to have 
been contributed by other people looking at your code which doesn't inspire 
a lot of confidence in you... Even Alan Cox said a while ago that you have 
his vote of no confidence (probably slightly rephrased here) because of 
changes you were introducing and I tend to trust bearded kernel hackers 
from Whales. (-;

Aren't you noticing that something is wrong here???

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

 [ First off: any IDE-only thing that doesn't work for SCSI or other disks
   doesn't solve a generic problem, so the complaint that some generic
   tools might use it is totally invalid. ]

On Tue, 7 May 2002, Anton Altaparmakov wrote:
>
> Linux's power is exactly that it can be used on anything from a wristwatch
> to a huge server and that it is flexible about everything. You are breaking
> this flexibility for no apparent reason. (I don't accept "I can't cope with
> this so I remove it." as a reason, sorry).

Run the 57 patch, and complain if something doesn't work.

Linux's power is that we FIX stuff. That we make it the best system
possible, and that we don't just whine and argue about things.

> As the new IDE maintainer so far we have only seen you removing one
> feature after the other in the name of cleanup, without adequate or even
> any at all(!) replacements,

Who cares? Have you found _anything_ that Martin removed that was at all
worthwhile? I sure haven't.

Guys, you have to realize that the IDE layer has eight YEARS of absolute
crap in it. Seriously. It's _never_ been cleaned up before. It has stuff
so distasteful that t's scary.

Take it from me: it's a _lot_ easier to add cruft and crap on top of clean
code. You can do it yourself if you want to. You don't need a maintainer
to add barnacles.

All the information that /proc/ide gave you is basically available in
hdparm, and for your dear embedded system it apparently takes up less
space by being in user space. So what is the problem?

My vote is to remove as much as humanly possible.

	"Everything should be made as simple as possible, but not
	 simpler" - Albert Einstein

Think about it, and really _understand_ it.

			Linus

Re: [PATCH] 2.5.14 IDE 56

[Jan Harkes]

On Tue, May 07, 2002 at 08:36:54AM -0700, Linus Torvalds wrote:
> On Tue, 7 May 2002, Anton Altaparmakov wrote:
> > As the new IDE maintainer so far we have only seen you removing one
> > feature after the other in the name of cleanup, without adequate or even
> > any at all(!) replacements,
> 
> Who cares? Have you found _anything_ that Martin removed that was at all
> worthwhile? I sure haven't.

I'm still hoping a patch will show up that will allow me to regain
access to my compactflash cards and IBM microdrive disks. The code
currently doesn't rescan for new drives when a card has been inserted,
although it still seems to have all the necessary logic.

Jan

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Jan Harkes napisa?:
> On Tue, May 07, 2002 at 08:36:54AM -0700, Linus Torvalds wrote:
> 
>>On Tue, 7 May 2002, Anton Altaparmakov wrote:
>>
>>>As the new IDE maintainer so far we have only seen you removing one
>>>feature after the other in the name of cleanup, without adequate or even
>>>any at all(!) replacements,
>>
>>Who cares? Have you found _anything_ that Martin removed that was at all
>>worthwhile? I sure haven't.
> 
> 
> I'm still hoping a patch will show up that will allow me to regain
> access to my compactflash cards and IBM microdrive disks. The code
> currently doesn't rescan for new drives when a card has been inserted,
> although it still seems to have all the necessary logic.
> 

Yes I'm fully aware of this, but the whole initialization
is currently much in flux and I will return to this issue back
if I think that things are in shape there. OK?

Re: [PATCH] 2.5.14 IDE 56

[Jan Harkes]

On Tue, May 07, 2002 at 05:26:10PM +0200, Martin Dalecki wrote:
> Uz.ytkownik Jan Harkes napisa?:
> >I'm still hoping a patch will show up that will allow me to regain
> >access to my compactflash cards and IBM microdrive disks. The code
> >currently doesn't rescan for new drives when a card has been inserted,
> >although it still seems to have all the necessary logic.
> 
> Yes I'm fully aware of this, but the whole initialization
> is currently much in flux and I will return to this issue back
> if I think that things are in shape there. OK?

I thought so, you already indicated so around the time that it broke.
There is still a 2.4 kernel when I really need to get to the data.

Jan

Re: [PATCH] 2.5.14 IDE 56

[Guest section DW]

On Tue, May 07, 2002 at 05:36:03PM -0400, Jan Harkes wrote:
> On Tue, May 07, 2002 at 05:26:10PM +0200, Martin Dalecki wrote:
> > Uz.ytkownik Jan Harkes napisa?:
> > >I'm still hoping a patch will show up that will allow me to regain
> > >access to my compactflash cards and IBM microdrive disks. The code
> > >currently doesn't rescan for new drives when a card has been inserted,
> > >although it still seems to have all the necessary logic.
> > 
> > Yes I'm fully aware of this, but the whole initialization
> > is currently much in flux and I will return to this issue back
> > if I think that things are in shape there. OK?
> 
> I thought so, you already indicated so around the time that it broke.
> There is still a 2.4 kernel when I really need to get to the data.

I usually do

	blockdev --rereadpt /dev/sde

or so. That still works for me with 2.5.13.

Andries

Re: [PATCH] 2.5.14 IDE 56

[Jan Harkes]

On Wed, May 08, 2002 at 02:25:13AM +0200, Guest section DW wrote:
> On Tue, May 07, 2002 at 05:36:03PM -0400, Jan Harkes wrote:
> > On Tue, May 07, 2002 at 05:26:10PM +0200, Martin Dalecki wrote:
> > > Uz.ytkownik Jan Harkes napisa?:
> > > >I'm still hoping a patch will show up that will allow me to regain
> > > >access to my compactflash cards and IBM microdrive disks. The code
> > > >currently doesn't rescan for new drives when a card has been inserted,
> > > >although it still seems to have all the necessary logic.
> > > 
> > > Yes I'm fully aware of this, but the whole initialization
> > > is currently much in flux and I will return to this issue back
> > > if I think that things are in shape there. OK?
> > 
> > I thought so, you already indicated so around the time that it broke.
> > There is still a 2.4 kernel when I really need to get to the data.
> 
> I usually do
> 
> 	blockdev --rereadpt /dev/sde
> 
> or so. That still works for me with 2.5.13.

For SCSI devices probably, but I get "/dev/hde: No such device" (ENODEV)
when a CF card is inserted and recognized.

    (dmesg)
    hde: SanDisk SDCFB-32, ATA DISK drive
    ide2 at 0x100-0x107,0x10e on irq 3
    ide_cs: hde: Vcc = 3.3, Vpp = 0.0

When the CF card is not inserted I get a subtly different error
"/dev/hde: No such device or address" (ENXIO).

It looks like the drive <-> driver association is only set up when the
ide-disk driver module is loaded and not when new hardware is found.

Jan

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Guest section DW napisa?:
> On Tue, May 07, 2002 at 05:36:03PM -0400, Jan Harkes wrote:
> 
>>On Tue, May 07, 2002 at 05:26:10PM +0200, Martin Dalecki wrote:
>>
>>>Uz.ytkownik Jan Harkes napisa?:
>>>
>>>>I'm still hoping a patch will show up that will allow me to regain
>>>>access to my compactflash cards and IBM microdrive disks. The code
>>>>currently doesn't rescan for new drives when a card has been inserted,
>>>>although it still seems to have all the necessary logic.
>>>
>>>Yes I'm fully aware of this, but the whole initialization
>>>is currently much in flux and I will return to this issue back
>>>if I think that things are in shape there. OK?
>>
>>I thought so, you already indicated so around the time that it broke.
>>There is still a 2.4 kernel when I really need to get to the data.
> 
> 
> I usually do
> 
> 	blockdev --rereadpt /dev/sde
> 
> or so. That still works for me with 2.5.13.


What you have to do by hand now is the rescanning for partition
information. What you do is triggering just that. And if I think
about it... and you know I'm evil... hmmm...
well why just don't let it be like that. It's functionally somehow the
responsibility of the /sbin/hotplug thing anyway...

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> about it... and you know I'm evil... hmmm...
> well why just don't let it be like that. It's functionally somehow the
> responsibility of the /sbin/hotplug thing anyway...

How do you intend to order a sequence of I/O operations precisely against a 
partition table change driven from user space ? Thats one I can't see a nice 
answer for, and having a raid controller that can do on the fly volume
resizing/creation/deletion its not just a matter of curiosity

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>about it... and you know I'm evil... hmmm...
>>well why just don't let it be like that. It's functionally somehow the
>>responsibility of the /sbin/hotplug thing anyway...
> 
> 
> How do you intend to order a sequence of I/O operations precisely against a 
> partition table change driven from user space ? Thats one I can't see a nice 
> answer for, and having a raid controller that can do on the fly volume
> resizing/creation/deletion its not just a matter of curiosity


Nahh Alan we are just talking about the ide-cs stuff. I'm not that "evil".

Re: [PATCH] 2.5.14 IDE 56

[Padraig Brady]

Linus Torvalds wrote:
>  [ First off: any IDE-only thing that doesn't work for SCSI or other disks
>    doesn't solve a generic problem, so the complaint that some generic
>    tools might use it is totally invalid. ]
> 
> On Tue, 7 May 2002, Anton Altaparmakov wrote:
> 
>>Linux's power is exactly that it can be used on anything from a wristwatch
>>to a huge server and that it is flexible about everything. You are breaking
>>this flexibility for no apparent reason. (I don't accept "I can't cope with
>>this so I remove it." as a reason, sorry).
> 
> 
> Run the 57 patch, and complain if something doesn't work.
> 
> Linux's power is that we FIX stuff. That we make it the best system
> possible, and that we don't just whine and argue about things.
> 
> 
>>As the new IDE maintainer so far we have only seen you removing one
>>feature after the other in the name of cleanup, without adequate or even
>>any at all(!) replacements,
> 
> 
> Who cares? Have you found _anything_ that Martin removed that was at all
> worthwhile? I sure haven't.
> 
> Guys, you have to realize that the IDE layer has eight YEARS of absolute
> crap in it. Seriously. It's _never_ been cleaned up before. It has stuff
> so distasteful that t's scary.
> 
> Take it from me: it's a _lot_ easier to add cruft and crap on top of clean
> code. You can do it yourself if you want to. You don't need a maintainer
> to add barnacles.
> 
> All the information that /proc/ide gave you is basically available in
> hdparm, and for your dear embedded system it apparently takes up less
> space by being in user space. So what is the problem?

Well my "dear" embedded system doesn't have libc :-(
So 35664 saved in kernel (less on disk), requires 25212
extra for hdparm + more for static linked uclibc (hope
it works ;-)). As a side note if this happens hdparm would
be a requirement for busybox IMHO, anyway getting back on topic...

All the info I've ever needed is /proc/ide/hdx/capacity
which I could get from /proc/partitions with more a bit
more effort, so I vote for removing /proc/ide.

I think everyone realises Martin is doing great and much needed work
on IDE (btw I'll have those flash support patches soon Martin ;-)),
but I did think this change needed debate. In general I know it's a
hard decision what to export in proc, especially if there are
existing dependencies, a few already mentioned possibles in RH7.1:

/sbin/mkinitrd
/sbin/fdisk
/sbin/sfdisk
/sbin/sndconfig
/usr/sbin/mouseconfig
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/updfstab
/usr/sbin/glidelink
/usr/sbin/sndconfig
/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/bin/X11/Xconfigurator

For e.g. could the same arguments could be made for lspci only
interface to pci info rather than /proc/bus/pci? The following
references are made to /proc/bus/pci on my system:

/sbin/lspci
/sbin/setpci
/sbin/sndconfig
/usr/sbin/mouseconfig
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/updfstab
/usr/sbin/glidelink
/usr/sbin/sndconfig
/usr/sbin/adsl-config
/usr/sbin/internet-config
/usr/sbin/isdn-config
/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/bin/X11/XFree86
/usr/bin/X11/pcitweak
/usr/bin/X11/scanpci
/usr/bin/X11/Xconfigurator

cheers,
Padraig.

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

On Tue, 7 May 2002, Padraig Brady wrote:
>
> All the info I've ever needed is /proc/ide/hdx/capacity
> which I could get from /proc/partitions with more a bit
> more effort, so I vote for removing /proc/ide.

Note that one thing that we might do is to leave the remnants of /proc/ide
but _without_ the very verbose per-chipset reporting.

At least to me it looks like it's all the chipset reporting that causes
the huge kernel bloat, and it shouldn't be impossible to reinstate a
minimal /proc/ide without those parts - while still keeping most of the
backwards compatibility.

However, since I really don't much like the idea of having special
"ide-only" /proc files, I personally think any information people actually
used should be either in truly generic files (/proc/partitions as an
example), _or_ they should be in the generic device tree (talk to Pat
Mochel about that).

So my personal reaction to removal of /proc/ide is: "good riddance, but if
it turns out that we seriously need it for backwards compatibility, we can
add back a skeleton without the bloat".

(Side note: I'm afraid that don't think backwards compatibility weighs
very heavily on an embedded setup - I'm more thinking about things like "a
regular RedHat/SuSE/Debian/whatever install won't work any more".)

As to existing binaries (your list is interesting), I don't see what they
are doing about ide-specific stuff, since I sure hope those binaries are
happy with a SCSI-only system.

> For e.g. could the same arguments could be made for lspci only
> interface to pci info rather than /proc/bus/pci? The following
> references are made to /proc/bus/pci on my system:

I personally do like ASCII /proc files, as long as they don't add
maintainability problems etc.

		Linus

Re: [PATCH] 2.5.14 IDE 56

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 07.05.02 in <Pine.LNX.4.44.0205070944020.2509-100000@home.transmeta.com>:

> On Tue, 7 May 2002, Padraig Brady wrote:
> >
> > All the info I've ever needed is /proc/ide/hdx/capacity
> > which I could get from /proc/partitions with more a bit
> > more effort, so I vote for removing /proc/ide.
>
> Note that one thing that we might do is to leave the remnants of /proc/ide
> but _without_ the very verbose per-chipset reporting.
>
> At least to me it looks like it's all the chipset reporting that causes
> the huge kernel bloat, and it shouldn't be impossible to reinstate a
> minimal /proc/ide without those parts - while still keeping most of the
> backwards compatibility.

What I'd like to see - in whatever exact form - is the IDE equivalent to  
/proc/scsi/scsi. (And in fact, the SCSI version could use addition of at  
least the disk size and the sdX mapping.)

It's rather useful for getting a quick overview of what's on a system, and  
where.

Incidentally, is there a compelling reason why block device boot messages  
are all different?

> However, since I really don't much like the idea of having special
> "ide-only" /proc files, I personally think any information people actually
> used should be either in truly generic files (/proc/partitions as an
> example), _or_ they should be in the generic device tree (talk to Pat
> Mochel about that).

/proc/bus/ide or something like that? Sure, why not? Exact place is pretty  
much irrelevant except to legacy code.

MfG Kai

Re: [PATCH] 2.5.14 IDE 56

[Juan Quintela]

>>>>> "linus" == Linus Torvalds <torvalds@transmeta.com> writes:

Hi

linus> (Side note: I'm afraid that don't think backwards compatibility weighs
linus> very heavily on an embedded setup - I'm more thinking about things like "a
linus> regular RedHat/SuSE/Debian/whatever install won't work any more".)

here at Mandrake we have a patch for the install kernel to remove the
/proc/ide, and  I think that we got it from redhat, that means that at
least two distros preffer to save ~25kb in the boot kernels than the
reporting that they do :p

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

On 8 May 2002, Juan Quintela wrote:
> linus> (Side note: I'm afraid that don't think backwards compatibility weighs
> linus> very heavily on an embedded setup - I'm more thinking about things like "a
> linus> regular RedHat/SuSE/Debian/whatever install won't work any more".)
>
> here at Mandrake we have a patch for the install kernel to remove the
> /proc/ide, and  I think that we got it from redhat, that means that at
> least two distros preffer to save ~25kb in the boot kernels than the
> reporting that they do :p

Well, that's a good sign in that it implies that things certainyl work
fine without /proc/ide.

However, I think I phrased things badly: I'm not actually worried about
the RedHat or Mandrake "act of installation" itself - since that will
always use whatever kernel RH or Mandrake put on their CD's, and they can
always change their install scripts/programs to match the kernel they use.

I'm more worried about the issue of "I installed RH-x.x, and then I
upgraded the kernel, and now program xyz won't work any more", where "xyz"
is something perfectly reasonable and common.

For example, let's say that some strange version of "mount" _requires_
/proc/ide to work (don't ask me why), and that Mandrake happened to ship
that version in their 8.2 release, and if you use the new 2.5.15 kernel on
that installation, it simply won't work. THAT would be a problem where
some backwards compatibility crud is probably worth it.

But if /proc/ide removal breaks an embedded device (on which the kernel is
not normally upgraded by "normal" people that aren't willing to upgrade
other stuff at the same time), I won't worry too much. Or if the /proc/ide
changs mean that the actual installer has to be re-done, I won't worry.

And even breaking one or two applications might be quite acceptable: I
worry more about maintainability than _perfect_ backwards compatibility.

		Linus

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> All the info I've ever needed is /proc/ide/hdx/capacity
> which I could get from /proc/partitions with more a bit
> more effort, so I vote for removing /proc/ide.

/proc/ide has useful information in it that you can't get easily by
other means at the moment - which controller is driving the disks, what
devices are present etc.

> For e.g. could the same arguments could be made for lspci only
> interface to pci info rather than /proc/bus/pci? The following
> references are made to /proc/bus/pci on my system:

lspci relies on /proc/bus/pci - its the only part of the universe that
actually knows how to handle PCI and virtualised PCI devices. Unlike the
older /proc/pci interface it keeps all the complex gunk out of the kernel

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

On Tue, 7 May 2002, Alan Cox wrote:
>
> /proc/ide has useful information in it that you can't get easily by
> other means at the moment - which controller is driving the disks, what
> devices are present etc.

I'd love for somebody to add the devices to the real device tree, at which
point this kind of information would be very much visible..

Right now devicefs isn't even mounted by default, but it's the only
_really_ generic way of showing things like this that we have. For people
who haven't seen it before, do a

	mount -t driverfs /devfs /devfs

and go look in there.. In particular, if you have a PCI system with a USB
device tree (or _multiple_ such trees), notice how you can look at things
like

	/driverfs/root/pci0/00:1f.4/usb_bus/000/

and it wouldn't be impossible (or even necessarily very hard) to make an
IDE controller export the "IDE device tree" the same way a USB controller
now exports the "USB device tree".

For things like hotplug etc, I think driverfs is eventually the only way
to go, simply because it gives you the full (and unambiguous) path to
_any_ device, and is completely bus-agnostic.

But there is definitely a potential backwards-compatibility-issue.

		Linus

Re: [PATCH] 2.5.14 IDE 56

[benh]

>	/driverfs/root/pci0/00:1f.4/usb_bus/000/
>
>and it wouldn't be impossible (or even necessarily very hard) to make an
>IDE controller export the "IDE device tree" the same way a USB controller
>now exports the "USB device tree".
>
>For things like hotplug etc, I think driverfs is eventually the only way
>to go, simply because it gives you the full (and unambiguous) path to
>_any_ device, and is completely bus-agnostic.
>
>But there is definitely a potential backwards-compatibility-issue.

One interesting thing here would be to have some optional link between
the bus-oriented device tree and the function-oriented tree (ie. devfs
or simply /dev). For example, an IDE node in driverfs could eventually
hold symlinks to the entries it provides in /dev when using devfs (or
just provide major/minor when not using devfs).

What do you think ?

One problem I've been faced with on ppc is to be able to match
a linux device with what the firmware (Open Firmware) thinks that
device is. The firmware view is bus-centered and it would be pretty
easy to provide some additional entries in driverfs that give the
OF fullpath of a given device. But then, the link between the actual
driver in driverfs and the "device" as used by, for example, the
filesystem isn't trivial.

Ben.

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

On Tue, 7 May 2002 benh@kernel.crashing.org wrote:
>
> One interesting thing here would be to have some optional link between
> the bus-oriented device tree and the function-oriented tree (ie. devfs
> or simply /dev).

There isn't any 1:1 thing - the device/bus-oriented one should _not_ show
virtual things like partitions etc that have no relevance for a driver,
while /dev (and thus devfs) obviously think that that is the important
part, much more important than how we actually got to the device.

I think we need to have some way of getting a mapping from /dev ->
devicefs, but I don't think that has to be a filesystem thing (it might
even be as simple as just one ioctl or new system call: 'get the "path" of
this device').

There aren't that many people who actually care, I suspect.

		Linus

Re: [PATCH] 2.5.14 IDE 56

[benh]

>
>
>On Tue, 7 May 2002 benh@kernel.crashing.org wrote:
>>
>> One interesting thing here would be to have some optional link between
>> the bus-oriented device tree and the function-oriented tree (ie. devfs
>> or simply /dev).
>
>There isn't any 1:1 thing - the device/bus-oriented one should _not_ show
>virtual things like partitions etc that have no relevance for a driver,
>while /dev (and thus devfs) obviously think that that is the important
>part, much more important than how we actually got to the device.
>
>I think we need to have some way of getting a mapping from /dev ->
>devicefs, but I don't think that has to be a filesystem thing (it might
>even be as simple as just one ioctl or new system call: 'get the "path" of
>this device').
>
>There aren't that many people who actually care, I suspect.

Sure, It's obviously not 1:1, what I had in mind was for the controller
to show what devices it exports in the sense of raw devices, but I agree
the other way makes a lot more sense. My problem was how to be devfs
agnostic, but you answered with "ioctl or syscall" and that would indeed
be ok. The ioctl things make it appliable to network interfaces as well,
which is good.

The need to do this link from a /dev to the driverfs, I suspect, will exist
only for case like setting up the firmware, though I can imagine one may
want to tweak some IDE settings (available via driverfs in your proposed
scheme) knowing only the /dev node.

Ben.

Re: [PATCH] 2.5.14 IDE 56

[Mike Fedyk]

On Tue, May 07, 2002 at 07:30:34PM +0200, benh@kernel.crashing.org wrote:
> >
> >
> >On Tue, 7 May 2002 benh@kernel.crashing.org wrote:
> >>
> >> One interesting thing here would be to have some optional link between
> >> the bus-oriented device tree and the function-oriented tree (ie. devfs
> >> or simply /dev).
> >
> >There isn't any 1:1 thing - the device/bus-oriented one should _not_ show
> >virtual things like partitions etc that have no relevance for a driver,
> >while /dev (and thus devfs) obviously think that that is the important
> >part, much more important than how we actually got to the device.
> >
> >I think we need to have some way of getting a mapping from /dev ->
> >devicefs, but I don't think that has to be a filesystem thing (it might
> >even be as simple as just one ioctl or new system call: 'get the "path" of
> >this device').
> >
> >There aren't that many people who actually care, I suspect.
> 
> Sure, It's obviously not 1:1, what I had in mind was for the controller
> to show what devices it exports in the sense of raw devices, but I agree
> the other way makes a lot more sense. My problem was how to be devfs
> agnostic, but you answered with "ioctl or syscall" and that would indeed
> be ok. The ioctl things make it appliable to network interfaces as well,
> which is good.

Yes, when will we get something that associates the physical device with
network ethX name?

Re: [PATCH] 2.5.14 IDE 56

[Richard Gooch]

Linus Torvalds writes:
> On Tue, 7 May 2002 benh@kernel.crashing.org wrote:
> >
> > One interesting thing here would be to have some optional link between
> > the bus-oriented device tree and the function-oriented tree (ie. devfs
> > or simply /dev).
> 
> There isn't any 1:1 thing - the device/bus-oriented one should _not_
> show virtual things like partitions etc that have no relevance for a
> driver, while /dev (and thus devfs) obviously think that that is the
> important part, much more important than how we actually got to the
> device.

Actually, I've always said that I think devfs should care about both
views. And that's why I think putting the driver tree (ala driverfs)
in devfs, and making the device-oriented part of the tree be symlinks
into the bus-oriented tree, is a good idea.

> I think we need to have some way of getting a mapping from /dev ->
> devicefs, but I don't think that has to be a filesystem thing (it
> might even be as simple as just one ioctl or new system call: 'get
> the "path" of this device').

Fugly. What's wrong with readlink(2) as this "magic syscall"?

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

On Tue, 7 May 2002, Richard Gooch wrote:
>
> Actually, I've always said that I think devfs should care about both
> views.

And I think you're completely wrong.

The fact is, they are two completely different and orthogonal things, and
they have _nothing_ in common except for a very weak linkage of actual
"physical device" (which does not always exist).

The set of people that cares about one view is almost 100% different from
the set of people that care about the other view.

> Fugly. What's wrong with readlink(2) as this "magic syscall"?

Ehh - like the fact that it doesn't work on device files?

		Linus

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> > Fugly. What's wrong with readlink(2) as this "magic syscall"?
> Ehh - like the fact that it doesn't work on device files?

I can't find anything in Posix/SuS that says it isnt allowed to however 8)

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

On Tue, 7 May 2002, Alan Cox wrote:
>
> > > Fugly. What's wrong with readlink(2) as this "magic syscall"?
> > Ehh - like the fact that it doesn't work on device files?
>
> I can't find anything in Posix/SuS that says it isnt allowed to however 8)

We can certainly do it, it just doesn't buy us much of anything, since
none of the standard tools (ie "ls") will actually do the readlink() for
anything but a symlink.

So at that point it's just another magic syscall, except we've overloaded
an old one.

Which may certainly be acceptable, of course.

		Linus

Re: [PATCH] 2.5.14 IDE 56

[Richard Gooch]

Linus Torvalds writes:
> 
> 
> On Tue, 7 May 2002, Alan Cox wrote:
> >
> > > > Fugly. What's wrong with readlink(2) as this "magic syscall"?
> > > Ehh - like the fact that it doesn't work on device files?
> >
> > I can't find anything in Posix/SuS that says it isnt allowed to however 8)
> 
> We can certainly do it, it just doesn't buy us much of anything, since
> none of the standard tools (ie "ls") will actually do the readlink() for
> anything but a symlink.
> 
> So at that point it's just another magic syscall, except we've overloaded
> an old one.
> 
> Which may certainly be acceptable, of course.

I wasn't suggesting a magic readlink(2). I was suggesting a *real*
one. Device nodes get stored in the physical tree (what you call
driverfs), and the entries in the logical tree are symlinks. Such as:

	/dev/scsi/host0  symlink to  /dev/bus/pci0/slot1/function2

or something like that. Easy to implement, easy to understand, easy to
manage.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] 2.5.14 IDE 56

[Linus Torvalds]

On Tue, 7 May 2002, Richard Gooch wrote:
> > Which may certainly be acceptable, of course.
>
> I wasn't suggesting a magic readlink(2). I was suggesting a *real*
> one. Device nodes get stored in the physical tree (what you call
> driverfs), and the entries in the logical tree are symlinks.

NO.

This is one backwards compatibility thing that I'm _not_ removing.

We have tons of existign /dev trees, and I'm not making them into
symlinks.

Also, you obviously haven't thought it through AT ALL. Hint: partitions.

If you have /dev/hda1, that _cannot_ be a symlink to the physical tree,
because on a physical level that partition DOES NOT EXIST. It's purely a
virtual mapping.

Yet clearly there _is_ a mapping from /dev/hda1 onto the physical device
in question, and clearly it _is_ a meaninful operation to operate on the
physical device underlying /dev/hda1.

So if you want to have a sane interface, you need to have a way to look up
the physical device that underlies /dev/hda1.

Yet it clearly cannot be a symlink.

QED.

So stop mixing up physical devices and /dev. They should NOT be handled by
the same mechanism.

		Linus

Re: [PATCH] 2.5.14 IDE 56

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Linus Torvalds wrote:

> Also, you obviously haven't thought it through AT ALL. Hint: partitions.
> 
> If you have /dev/hda1, that _cannot_ be a symlink to the physical tree,
> because on a physical level that partition DOES NOT EXIST. It's purely a
> virtual mapping.
> 
> Yet clearly there _is_ a mapping from /dev/hda1 onto the physical device
> in question, and clearly it _is_ a meaninful operation to operate on the
> physical device underlying /dev/hda1.
> 
> So if you want to have a sane interface, you need to have a way to look up
> the physical device that underlies /dev/hda1.
> 
> Yet it clearly cannot be a symlink.
> 
> QED.

Somehow I expect Al to step in with something like:

mount -t partfs /devfs/bus/... /dev/hda

:-)

bye, Roman

Re: [PATCH] 2.5.14 IDE 56

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 07.05.02 in <Pine.LNX.4.44.0205071142001.1067-100000@home.transmeta.com>:

> If you have /dev/hda1, that _cannot_ be a symlink to the physical tree,
> because on a physical level that partition DOES NOT EXIST. It's purely a
> virtual mapping.

Well ... one *could* argue that there's justification for showing those  
partitions by the exact same argument that there's reason to show devices  
on a SCSI or USB bus. It's just going further down the tree.

Say something like

        /driverfs/root/pci0/00:1f.4/scsi_bus/003/pc_partition/2

Sure, it's software, not hardware. OTOH, it's one of the things that  
change with hotplug. (And incidentally, fdisk changing partitions *might*  
be handled somewhat like a hotplug event ...)

As to linking to /dev, I see no reason why you couldn't have that tree  
include information (not in the tree *structure*, obviously) of what the  
relevant device numbers are. That's more expensive than a lookup with a  
pointer gotten from /dev, but it's certainly possible.

MfG Kai

Re: [PATCH] 2.5.14 IDE 56

[Ian Molton]

On 08 May 2002 08:57:00 +0200
kaih@khms.westfalen.de (Kai Henningsen) wrote:

>    /driverfs/root/pci0/00:1f.4/scsi_bus/003/pc_partition/2
> 
> Sure, it's software, not hardware.

I agree. I think it'd be great to have something like the above.

Re: [PATCH] 2.5.14 IDE 56

[Pavel Machek]

Hi!

> Also, you obviously haven't thought it through AT ALL. Hint: partitions.
> 
> If you have /dev/hda1, that _cannot_ be a symlink to the physical tree,
> because on a physical level that partition DOES NOT EXIST. It's purely a
> virtual mapping.

I don't see why partitions in devicefs are bad idea.

Some physical chips show as multiple devices in devicefs, so I'd guess it
would be okay for partitions to be there, too.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Użytkownik Richard Gooch napisał:
> Linus Torvalds writes:
> 
>>
>>On Tue, 7 May 2002, Alan Cox wrote:
>>
>>>>>Fugly. What's wrong with readlink(2) as this "magic syscall"?
>>>>
>>>>Ehh - like the fact that it doesn't work on device files?
>>>
>>>I can't find anything in Posix/SuS that says it isnt allowed to however 8)
>>
>>We can certainly do it, it just doesn't buy us much of anything, since
>>none of the standard tools (ie "ls") will actually do the readlink() for
>>anything but a symlink.
>>
>>So at that point it's just another magic syscall, except we've overloaded
>>an old one.
>>
>>Which may certainly be acceptable, of course.
> 
> 
> I wasn't suggesting a magic readlink(2). I was suggesting a *real*
> one. Device nodes get stored in the physical tree (what you call
> driverfs), and the entries in the logical tree are symlinks. Such as:
> 
> 	/dev/scsi/host0  symlink to  /dev/bus/pci0/slot1/function2
> 
> or something like that. Easy to implement, easy to understand, easy to
> manage.

Now you take the last step toward solaris and realize why I was
always against your solution (no personal offence)
to the device management problem - they do it all in user space
by precisely the above symlink system....

Re: [PATCH] 2.5.14 IDE 56

[Jauder Ho]

Ben, what you are proposing is fairly similar to what Solaris does today.
There is a /devices directory that contains the real path while /dev
contains the legacy stuff. Seems to work fine and given the proper docs,
you can decipher what the /devices path points to fairly easily. So I
certainly wouldnt mind seeing this happen for Linux eventually.

--Jauder

On Tue, 7 May 2002 benh@kernel.crashing.org wrote:

> >	/driverfs/root/pci0/00:1f.4/usb_bus/000/
> >
> >and it wouldn't be impossible (or even necessarily very hard) to make an
> >IDE controller export the "IDE device tree" the same way a USB controller
> >now exports the "USB device tree".
> >
> >For things like hotplug etc, I think driverfs is eventually the only way
> >to go, simply because it gives you the full (and unambiguous) path to
> >_any_ device, and is completely bus-agnostic.
> >
> >But there is definitely a potential backwards-compatibility-issue.
>
> One interesting thing here would be to have some optional link between
> the bus-oriented device tree and the function-oriented tree (ie. devfs
> or simply /dev). For example, an IDE node in driverfs could eventually
> hold symlinks to the entries it provides in /dev when using devfs (or
> just provide major/minor when not using devfs).
>
> What do you think ?
>
> One problem I've been faced with on ppc is to be able to match
> a linux device with what the firmware (Open Firmware) thinks that
> device is. The firmware view is bus-centered and it would be pretty
> easy to provide some additional entries in driverfs that give the
> OF fullpath of a given device. But then, the link between the actual
> driver in driverfs and the "device" as used by, for example, the
> filesystem isn't trivial.
>
> Ben.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Jauder Ho napisa?:
> Ben, what you are proposing is fairly similar to what Solaris does today.
> There is a /devices directory that contains the real path while /dev
> contains the legacy stuff. Seems to work fine and given the proper docs,
> you can decipher what the /devices path points to fairly easily. So I
> certainly wouldnt mind seeing this happen for Linux eventually.

Amen, We would only have to add a device special file
to some of the /devices Stuff and /dev/ could be a symlink tree
pointing there...

I have *intentionally* named the standard mounting point
of the devicefs /devices the time I added the description
how to mount it to the driver-model.txt. The following words
are from *me*:

This can be done permanently by providing the following entry into the
/dev/fstab (under the provision that the mount point does exist, of course):

none            /devices        driverfs    defaults            0       0

Or by hand on the command line:

~: mount -t driverfs none /devices



> 
> --Jauder
> 
> On Tue, 7 May 2002 benh@kernel.crashing.org wrote:
> 
> 
>>>	/driverfs/root/pci0/00:1f.4/usb_bus/000/
>>>
>>>and it wouldn't be impossible (or even necessarily very hard) to make an
>>>IDE controller export the "IDE device tree" the same way a USB controller
>>>now exports the "USB device tree".
>>>
>>>For things like hotplug etc, I think driverfs is eventually the only way
>>>to go, simply because it gives you the full (and unambiguous) path to
>>>_any_ device, and is completely bus-agnostic.
>>>
>>>But there is definitely a potential backwards-compatibility-issue.
>>
>>One interesting thing here would be to have some optional link between
>>the bus-oriented device tree and the function-oriented tree (ie. devfs
>>or simply /dev). For example, an IDE node in driverfs could eventually
>>hold symlinks to the entries it provides in /dev when using devfs (or
>>just provide major/minor when not using devfs).
>>
>>What do you think ?
>>
>>One problem I've been faced with on ppc is to be able to match
>>a linux device with what the firmware (Open Firmware) thinks that
>>device is. The firmware view is bus-centered and it would be pretty
>>easy to provide some additional entries in driverfs that give the
>>OF fullpath of a given device. But then, the link between the actual
>>driver in driverfs and the "device" as used by, for example, the
>>filesystem isn't trivial.
>>
>>Ben.
>>
>>
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
> 
> 
> 



-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R

Re: [PATCH] 2.5.14 IDE 56

[Patrick Mochel]

On Tue, 7 May 2002 benh@kernel.crashing.org wrote:

> >	/driverfs/root/pci0/00:1f.4/usb_bus/000/
> >
> >and it wouldn't be impossible (or even necessarily very hard) to make an
> >IDE controller export the "IDE device tree" the same way a USB controller
> >now exports the "USB device tree".
> >
> >For things like hotplug etc, I think driverfs is eventually the only way
> >to go, simply because it gives you the full (and unambiguous) path to
> >_any_ device, and is completely bus-agnostic.
> >
> >But there is definitely a potential backwards-compatibility-issue.
> 
> One interesting thing here would be to have some optional link between
> the bus-oriented device tree and the function-oriented tree (ie. devfs
> or simply /dev). For example, an IDE node in driverfs could eventually
> hold symlinks to the entries it provides in /dev when using devfs (or
> just provide major/minor when not using devfs).

I agree with such a concept, but as Linus said, it should go the other 
way, from the functional interface to physical interface. There are many 
details involved in doing such a thing, but it should work something like 
this:

The logical subystems (ide disks, networking, etc) would register with the 
device model core and get a directory in driverfs:

/driverfs/class/ide/

Devices would be discovered and get a driverfs directory representing the 
physical location of the device:

/driverfs/root/pci0/07.2/

Note that no drivers have been bound to the device. When the driver is 
bound, it registers the device with the subsystem, passing in a 
subsystem-specific structure. These can be made to point in some way to 
the generic struct device of the device (from which the physical path can 
be inferred).

When this happens, the subsystem creates a directory underneath its 
driverfs directory, so you get:

/driverfs/class/ide/0/

And, a symlink is created to point to the directory in the physical path. 
As the driver discovers partitions on the device, it can create special 
nodes in its class directory. 

At this point, userspace can be notified (via /sbin/hotplug). That can 
create symlinks in /dev to the nodes that were just created, emulating 
current /dev behavior. 

So, what does this do? To an extent, it reengineers the funtionality of 
devfs. I'll be the first to admit it. However, it centers less around the 
filesystem, and more on the device model core. 

Most devices already register with their subsystems, so having the 
subsystesm pass device info onto the core is relatively easy. 

As partitions are discovered, you get paths like:

/driverfs/class/ide/0/2

Which gives you a default name for the device. With /sbin/hotplug, simple 
userspace policy, and symlinks in /dev, you can emulate the current device 
hierarchy. So, you get a device naming solution that gives you only the 
device names for the devices you have. 

This approach also de-emphasizes the dependency on major and minor 
numbers. If device nodes are created in kernel space initially, userspace 
doesn't need to know what the major/minor is for a particular device. The 
symlink to the device node is all that's need to operate on the device. 

Without the need to coordinate between kernel and userspace, at least some 
majors/minors can be dynamically allocated as the subsystems and devices 
are registered with the core. (These can then be exported via files in 
driverfs). (This is similar to the dynamic allocation of minor numbers in 
the USB subsystem that showed up recently...)

Oh, and it's with a modern, clean filesystem, 1/5 the size of devfs. 

Thoughts? Comments? Flames?

	-pat

Re: [PATCH] 2.5.14 IDE 56

[Greg KH]

On Tue, May 07, 2002 at 11:29:10AM -0700, Patrick Mochel wrote:
> 
> Which gives you a default name for the device. With /sbin/hotplug, simple 
> userspace policy, and symlinks in /dev, you can emulate the current device 
> hierarchy. So, you get a device naming solution that gives you only the 
> device names for the devices you have. 
> 
> This approach also de-emphasizes the dependency on major and minor 
> numbers. If device nodes are created in kernel space initially, userspace 
> doesn't need to know what the major/minor is for a particular device. The 
> symlink to the device node is all that's need to operate on the device. 
> 
> Without the need to coordinate between kernel and userspace, at least some 
> majors/minors can be dynamically allocated as the subsystems and devices 
> are registered with the core. (These can then be exported via files in 
> driverfs). (This is similar to the dynamic allocation of minor numbers in 
> the USB subsystem that showed up recently...)

And is exactly why this showed up in the USB subsystem :)

> Oh, and it's with a modern, clean filesystem, 1/5 the size of devfs. 

And it removes the dependency of devfsd and its interface, replacing it
with the existing /sbin/hotplug interface.  This allows different people
to implement different naming schemes if they so desire, moving naming
policy out of the kernel into userspace, where it belongs.

Yes, there will probably be a "default" naming scheme, matching what we
have today, but the ability to replace it with another one is _so_ much
easier than having to try to tie into devfsd (like the devreg
implementation does: http://www-124.ibm.com/devreg/ )


greg k-h

Re: [PATCH] 2.5.14 IDE 56

[Richard Gooch]

Patrick Mochel writes:
> Oh, and it's with a modern, clean filesystem, 1/5 the size of devfs. 

The size argument is not an issue. I've already said that devfs will
shrink a lot once I move tree management from my own code to the VFS.
At that point devfs will mostly be:
- an API
- a way fo supporting the devfsd protocol.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] 2.5.14 IDE 56

[Patrick Mochel]

On Tue, 7 May 2002, Richard Gooch wrote:

> Patrick Mochel writes:
> > Oh, and it's with a modern, clean filesystem, 1/5 the size of devfs. 
> 
> The size argument is not an issue. I've already said that devfs will
> shrink a lot once I move tree management from my own code to the VFS.

I agree 100%. However, I think that move will be very painful. I tried to 
do it a couple of months ago, and there were so many interdependencies and 
oddities that I gave up after about 6 hours.

> At that point devfs will mostly be:
> - an API
> - a way fo supporting the devfsd protocol.

I argue that you shouldn't need a separate daemon. We already have the 
/sbin/hotplug interface. It's simple and sweet. We shouldn't need to rely 
on an entirely separate daemon. 

	-pat

Re: [PATCH] 2.5.14 IDE 56

[Richard Gooch]

Patrick Mochel writes:
> 
> On Tue, 7 May 2002, Richard Gooch wrote:
> 
> > Patrick Mochel writes:
> > > Oh, and it's with a modern, clean filesystem, 1/5 the size of devfs. 
> > 
> > The size argument is not an issue. I've already said that devfs will
> > shrink a lot once I move tree management from my own code to the VFS.
> 
> I agree 100%. However, I think that move will be very painful. I
> tried to do it a couple of months ago, and there were so many
> interdependencies and oddities that I gave up after about 6 hours.

Oh, it's certainly more that 6 hours of work. But it *will* get done.

> > At that point devfs will mostly be:
> > - an API
> > - a way fo supporting the devfsd protocol.
> 
> I argue that you shouldn't need a separate daemon. We already have
> the /sbin/hotplug interface. It's simple and sweet. We shouldn't
> need to rely on an entirely separate daemon.

The devfsd protocol is more lightweight. Plus it doesn't require
fork(2)+execve(2) overheads. And more importantly, you can capture
lookup() events.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] 2.5.14 IDE 56

[Patrick Mochel]

> Oh, it's certainly more that 6 hours of work. But it *will* get done.

Even the mtrr driver was a good 8 hours to clean up, make readable and 
more object-oriented. I wish you luck, as well as anyone that has to 
attempt to decipher it. 

> > > At that point devfs will mostly be:
> > > - an API
> > > - a way fo supporting the devfsd protocol.
> > 
> > I argue that you shouldn't need a separate daemon. We already have
> > the /sbin/hotplug interface. It's simple and sweet. We shouldn't
> > need to rely on an entirely separate daemon.
> 
> The devfsd protocol is more lightweight. Plus it doesn't require
> fork(2)+execve(2) overheads. And more importantly, you can capture
> lookup() events.

These events are not performance critical, so the overhead is less 
important. Besides, almost all systems have /sbin/hotplug, since it can be 
anything - a shell script, a perl script, a tiny C executable. 

The hotplug interface doesn't rely on any particular implementation. It 
only relies on something on the other side implementing a particular 
interface. The implementation can be replaced, as well as the format of 
the policy, based on the constratints of the system or the whims of 
the distro. 

It also doesn't rely on a process running to capture events. What happens 
if the devfsd process is killed?

	-pat

Re: [PATCH] 2.5.14 IDE 56

[Thunder from the hill]

Hi,

> > >	/driverfs/root/pci0/00:1f.4/usb_bus/000/
> /driverfs/class/ide/
> /driverfs/root/pci0/07.2/
> /driverfs/class/ide/0/
> /driverfs/class/ide/0/2

Why not fixing devfs for that? My root directory is messed up enough. We 
have dev, proc, tmp, ...
We might have /dev/driver or such, which doesn't make the root directory 
any fuller. (And also not to disturb the newbies any further. It's hard a 
lot to explain to a windows user why he can't remove /proc and /dev, and 
what this is supposed to be.)
This is just my opinion...

Regards,
Thunder
-- 
if (errno == ENOTAVAIL)
    fprintf(stderr, "Error: Talking to Microsoft server!\n");

Re: [PATCH] 2.5.14 IDE 56

[Patrick Mochel]

On Tue, 7 May 2002, Thunder from the hill wrote:

> Hi,
> 
> > > >	/driverfs/root/pci0/00:1f.4/usb_bus/000/
> > /driverfs/class/ide/
> > /driverfs/root/pci0/07.2/
> > /driverfs/class/ide/0/
> > /driverfs/class/ide/0/2
> 
> Why not fixing devfs for that? My root directory is messed up enough. We 
> have dev, proc, tmp, ...

For one, I am of the camp that believes devfs is unfixable. 

For two, where driverfs is mounted is irrelevant: /driverfs, /sys, 
/proc/bus are all valid places. 

Besides, who cares what's in /? You have /home, which is all that really 
matters, no? 

> We might have /dev/driver or such, which doesn't make the root directory 
> any fuller. (And also not to disturb the newbies any further. It's hard a 
> lot to explain to a windows user why he can't remove /proc and /dev, and 
> what this is supposed to be.)

So don't give them root access. Or, explain to them that they're magic, 
like the pagefile.sys file. :)

	-pat

Re: [PATCH] 2.5.14 IDE 56

[Richard Gooch]

Patrick Mochel writes:
> 
> On Tue, 7 May 2002, Thunder from the hill wrote:
> 
> > Hi,
> > 
> > > > >	/driverfs/root/pci0/00:1f.4/usb_bus/000/
> > > /driverfs/class/ide/
> > > /driverfs/root/pci0/07.2/
> > > /driverfs/class/ide/0/
> > > /driverfs/class/ide/0/2
> > 
> > Why not fixing devfs for that? My root directory is messed up enough. We 
> > have dev, proc, tmp, ...
> 
> For one, I am of the camp that believes devfs is unfixable. 

But it's not actually broken, now that the locking is fixed.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] 2.5.14 IDE 56

[Russell King]

On Tue, May 07, 2002 at 04:03:50PM -0600, Richard Gooch wrote:
> But it's not actually broken, now that the locking is fixed.

Really?  What about the case of the missing BKL for device opens that
you haven't really commented on?

Seems like devfs _still_ has locking problems.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] 2.5.14 IDE 56

[Richard Gooch]

Russell King writes:
> On Tue, May 07, 2002 at 04:03:50PM -0600, Richard Gooch wrote:
> > But it's not actually broken, now that the locking is fixed.
> 
> Really?  What about the case of the missing BKL for device opens that
> you haven't really commented on?

I did comment to you, privately, saying I was waiting to see what the
consensus was on the issue of whether to move the BKL or not. I'll be
sending a patch later this week to fix it.

> Seems like devfs _still_ has locking problems.

A pretty minor one, given the comment I was responding to: "devfs is
unfixable". I've noticed that even Al has gone quiet on the "devfs
races" issue, now that the new code is in place :-)

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] 2.5.14 IDE 56

[Russell King]

On Wed, May 08, 2002 at 10:07:44AM -0600, Richard Gooch wrote:
> Russell King writes:
> > Really?  What about the case of the missing BKL for device opens that
> > you haven't really commented on?
> 
> I did comment to you, privately, saying I was waiting to see what the
> consensus was on the issue of whether to move the BKL or not. I'll be
> sending a patch later this week to fix it.

Yes, and hey, we still have the problem a week layer, even after the
discussion went dead.

> > Seems like devfs _still_ has locking problems.
> 
> A pretty minor one, given the comment I was responding to: "devfs is
> unfixable". I've noticed that even Al has gone quiet on the "devfs
> races" issue, now that the new code is in place :-)

Never the less, your comment about "no locking problems" is inaccurate.
devfs is calling at least one part of the kernel without obeying the
existing locking rules.  That's definitely a devfs bug.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Patrick Mochel napisa?:
> On Tue, 7 May 2002 benh@kernel.crashing.org wrote:
> 
> 
>>>	/driverfs/root/pci0/00:1f.4/usb_bus/000/
>>>
>>>and it wouldn't be impossible (or even necessarily very hard) to make an
>>>IDE controller export the "IDE device tree" the same way a USB controller
>>>now exports the "USB device tree".
>>>
>>>For things like hotplug etc, I think driverfs is eventually the only way
>>>to go, simply because it gives you the full (and unambiguous) path to
>>>_any_ device, and is completely bus-agnostic.
>>>
>>>But there is definitely a potential backwards-compatibility-issue.
>>
>>One interesting thing here would be to have some optional link between
>>the bus-oriented device tree and the function-oriented tree (ie. devfs
>>or simply /dev). For example, an IDE node in driverfs could eventually
>>hold symlinks to the entries it provides in /dev when using devfs (or
>>just provide major/minor when not using devfs).
> 
> 
> I agree with such a concept, but as Linus said, it should go the other 
> way, from the functional interface to physical interface. There are many 
> details involved in doing such a thing, but it should work something like 
> this:
> 
> The logical subystems (ide disks, networking, etc) would register with the 
> device model core and get a directory in driverfs:
> 
> /driverfs/class/ide/
> 
> Devices would be discovered and get a driverfs directory representing the 
> physical location of the device:
> 
> /driverfs/root/pci0/07.2/
> 
> Note that no drivers have been bound to the device. When the driver is 
> bound, it registers the device with the subsystem, passing in a 
> subsystem-specific structure. These can be made to point in some way to 
> the generic struct device of the device (from which the physical path can 
> be inferred).
> 
> When this happens, the subsystem creates a directory underneath its 
> driverfs directory, so you get:
> 
> /driverfs/class/ide/0/
> 
> And, a symlink is created to point to the directory in the physical path. 
> As the driver discovers partitions on the device, it can create special 
> nodes in its class directory. 
> 
> At this point, userspace can be notified (via /sbin/hotplug). That can 
> create symlinks in /dev to the nodes that were just created, emulating 
> current /dev behavior. 
> 
> So, what does this do? To an extent, it reengineers the funtionality of 
> devfs. I'll be the first to admit it. However, it centers less around the 
> filesystem, and more on the device model core. 
> 
> Most devices already register with their subsystems, so having the 
> subsystesm pass device info onto the core is relatively easy. 
> 
> As partitions are discovered, you get paths like:
> 
> /driverfs/class/ide/0/2

Just a side note...
Please please name it /devices/ Some old boys like me (age 30)
can gain from similarities with some quite common "legacy" systems.
We don't have to "invent" for the sake of it.

And /devices/ is the way I have named it in the corresponding
documentation.

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik benh@kernel.crashing.org napisa?:
>>	/driverfs/root/pci0/00:1f.4/usb_bus/000/
>>
>>and it wouldn't be impossible (or even necessarily very hard) to make an
>>IDE controller export the "IDE device tree" the same way a USB controller
>>now exports the "USB device tree".
>>
>>For things like hotplug etc, I think driverfs is eventually the only way
>>to go, simply because it gives you the full (and unambiguous) path to
>>_any_ device, and is completely bus-agnostic.
>>
>>But there is definitely a potential backwards-compatibility-issue.
> 
> 
> One interesting thing here would be to have some optional link between
> the bus-oriented device tree and the function-oriented tree (ie. devfs
> or simply /dev). For example, an IDE node in driverfs could eventually
> hold symlinks to the entries it provides in /dev when using devfs (or
> just provide major/minor when not using devfs).
> 
> What do you think ?
> 
> One problem I've been faced with on ppc is to be able to match
> a linux device with what the firmware (Open Firmware) thinks that
> device is. The firmware view is bus-centered and it would be pretty
> easy to provide some additional entries in driverfs that give the
> OF fullpath of a given device. But then, the link between the actual
> driver in driverfs and the "device" as used by, for example, the
> filesystem isn't trivial.
> 
> Ben.
> 
> 
> 

This is the "first" IDE controller on my notebook:

./devices/root/pci0/00:07.1/01f0
./devices/root/pci0/00:07.1/01f0/0
./devices/root/pci0/00:07.1/01f0/0/power
./devices/root/pci0/00:07.1/01f0/0/name
./devices/root/pci0/00:07.1/01f0/0/status
./devices/root/pci0/00:07.1/01f0/power
./devices/root/pci0/00:07.1/01f0/name
./devices/root/pci0/00:07.1/01f0/status

Guys I have done it already!

For your convenience I will attach the ata prefix to the
currently used port number in the next patch round.

OK?

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Linus Torvalds napisa?:
> 
> On Tue, 7 May 2002, Alan Cox wrote:
> 
>>/proc/ide has useful information in it that you can't get easily by
>>other means at the moment - which controller is driving the disks, what
>>devices are present etc.
> 
> 
> I'd love for somebody to add the devices to the real device tree, at which
> point this kind of information would be very much visible..
> 
> Right now devicefs isn't even mounted by default, but it's the only
> _really_ generic way of showing things like this that we have. For people
> who haven't seen it before, do a
> 
> 	mount -t driverfs /devfs /devfs
> 
> and go look in there.. In particular, if you have a PCI system with a USB
> device tree (or _multiple_ such trees), notice how you can look at things
> like
> 
> 	/driverfs/root/pci0/00:1f.4/usb_bus/000/
> 
> and it wouldn't be impossible (or even necessarily very hard) to make an
> IDE controller export the "IDE device tree" the same way a USB controller
> now exports the "USB device tree".
> 
> For things like hotplug etc, I think driverfs is eventually the only way
> to go, simply because it gives you the full (and unambiguous) path to
> _any_ device, and is completely bus-agnostic.
> 
> But there is definitely a potential backwards-compatibility-issue.

Linus - there are no backward compatibility issues here.
No single application from my system does mess with /proc/ide.
They showed you a list of programs which use /proc and not a list
of programs which use anything out of /proc/ide...
RedHat even disables all this chip set specific reporting in theyr
public kernels. OK kudzu is using it, but it does not *rely on it*.
Heck kudzu is running all the time I rebooted my system during
developement and nothing ugly did happen.

for fdisk on my notebook, well it runs just fine:

[root@kozaczek root]# fdisk /dev/hda

The number of cylinders for this disk is set to 2584.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
    (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/hda: 240 heads, 63 sectors, 2584 cylinders
Units = cylinders of 15120 * 512 bytes

    Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1         7     52888+  83  Linux
/dev/hda2             8      2556  19270440    5  Extended
/dev/hda4          2557      2584    211680   a0  IBM Thinkpad hibernation
/dev/hda5             8      2166  16322008+  83  Linux
/dev/hda6          2167      2219    400648+  82  Linux swap

Neither the programmer who wrote fdisk or cdrecord or anything else
was stiupid enough to use anything out there, since using a
simple ioctl is easier anyway. I *did* check them.
(Admittedly I don't care about kudzu, but fdisk an friends I was
fully aware of.)

BTW. If one needs the size of the disk well we could
attach it as a file size to the device file in /dev IMHO. Why not?

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> RedHat even disables all this chip set specific reporting in theyr
> public kernels. OK kudzu is using it, but it does not *rely on it*.

The boot kernel has a lot of it disabled not the main ones.

> Heck kudzu is running all the time I rebooted my system during
> developement and nothing ugly did happen.

I can't speak directly for the Kudzu maintainer but I can say that having
a sane way to obtain the list of ide devices (all of them not just non 
pcmcia) and the device bindings/type has been a long standing request.

If 2.6 breaks a 2.4 installer and nothing else I don't think its a big 
disaster and the cleanup may well be justified

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>RedHat even disables all this chip set specific reporting in theyr
>>public kernels. OK kudzu is using it, but it does not *rely on it*.
> 
> 
> The boot kernel has a lot of it disabled not the main ones.
> 
> 
>>Heck kudzu is running all the time I rebooted my system during
>>developement and nothing ugly did happen.
> 
> 
> I can't speak directly for the Kudzu maintainer but I can say that having
> a sane way to obtain the list of ide devices (all of them not just non 
> pcmcia) and the device bindings/type has been a long standing request.
> 
> If 2.6 breaks a 2.4 installer and nothing else I don't think its a big 
> disaster and the cleanup may well be justified


Well personally I would just love if there where a "go ahead and don't
care about "compatibility" for the following:

Make hdX gone and use the scsi device major/minor number stuff instead.

And then just making the ATA driver looking like if it where some
incapable SCSI would actually reduce tons of code from kudzu and
friends without the need for any adjustment there.

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> Make hdX gone and use the scsi device major/minor number stuff instead.
> And then just making the ATA driver looking like if it where some
> incapable SCSI would actually reduce tons of code from kudzu and
> friends without the need for any adjustment there.

The SCSI layer is significant overhead even in 2.5. Right now for example
it appears to be the primary bottleneck for the aacraid drivers.  ATA6 is
also more capable than SCSI in several areas regardless of the notional
market positioning.

Linus talked about having a /dev/disc/... which once you have 32bit dev_t
makes complete sense. What you don't do however is throw IDE through the
SCSI midlayer, you merely make the /dev/disc/ point call into the right
drivers - be they raid, scsi or ide. That also lets the scsi emulation
crap get ripped out of the megaraid and aacraid drivers which will up
performance.

Alan

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>Make hdX gone and use the scsi device major/minor number stuff instead.
>>And then just making the ATA driver looking like if it where some
>>incapable SCSI would actually reduce tons of code from kudzu and
>>friends without the need for any adjustment there.
> 
> 
> The SCSI layer is significant overhead even in 2.5. Right now for example
> it appears to be the primary bottleneck for the aacraid drivers.  ATA6 is
> also more capable than SCSI in several areas regardless of the notional
> market positioning.
> 
> Linus talked about having a /dev/disc/... which once you have 32bit dev_t
> makes complete sense. What you don't do however is throw IDE through the
> SCSI midlayer, you merely make the /dev/disc/ point call into the right
> drivers - be they raid, scsi or ide. That also lets the scsi emulation
> crap get ripped out of the megaraid and aacraid drivers which will up
> performance.
> 
> Alan

Alan... you have taken me wrong. What I mean is just the following.
Take away some minors from use by SCSI (or more propably a common repository)
and use the same ioctl numbers where possible. Perhaps implement
some ioctl here and there... not more!

Not the whole: "we are just another SCSI device on the driver level".
That would not make sense indeed. Since in esp. the SCSI mid-layer isn't
taht pritty too...

Re: [PATCH] 2.5.14 IDE 56

[Lincoln Dale]

At 01:42 PM 8/05/2002 +0100, Alan Cox wrote:
>The SCSI layer is significant overhead even in 2.5.

i did some benchmarking on a high-end dual P3 Xeon (Serverworks chipset ) 
with QLogic 2300 (2gbit/s) 64/66 Fibre Channel controllers.

using the '/dev/sgX' interface to issue scsi reads/writes allowed me to hit 
the magical limit of 200mbyte/sec throughput.  (basically just about 
linerate).  (simultaneous "sg_read if=/dev/sgX mmap=1 bs=512 count=35M"; 
sg_read from the sg-tools package)

doing the same test thru the block-layer was basically capped at around 
135mbyte/sec.  (simultaneous "dd if=/dev/sdX of=/dev/null bs=512 count=35M").

whether the bottleneck was copy-from-kernel-to-userspace (ie. exhaustion of 
Front-Side-Bus / memory bandwidth) or related to block-layer overhead and 
scsi layer overheads, i haven't yet validated, but at a ~35% performance 
difference is relatively significant nontheless.

cpu utlization on the sg interface was under 10%.  using 'dd' on the sd 
interface, both gigahertz P3 Xeons had 0% idle time.


cheers,

lincoln.

Re: [PATCH] 2.5.14 IDE 56

[Andrew Morton]

Lincoln Dale wrote:
> 
> At 01:42 PM 8/05/2002 +0100, Alan Cox wrote:
> >The SCSI layer is significant overhead even in 2.5.
> 
> i did some benchmarking on a high-end dual P3 Xeon (Serverworks chipset )
> with QLogic 2300 (2gbit/s) 64/66 Fibre Channel controllers.
> 
> using the '/dev/sgX' interface to issue scsi reads/writes allowed me to hit
> the magical limit of 200mbyte/sec throughput.  (basically just about
> linerate).  (simultaneous "sg_read if=/dev/sgX mmap=1 bs=512 count=35M";
> sg_read from the sg-tools package)
> 
> doing the same test thru the block-layer was basically capped at around
> 135mbyte/sec.  (simultaneous "dd if=/dev/sdX of=/dev/null bs=512 count=35M").
> 
> whether the bottleneck was copy-from-kernel-to-userspace (ie. exhaustion of
> Front-Side-Bus / memory bandwidth) or related to block-layer overhead and
> scsi layer overheads, i haven't yet validated, but at a ~35% performance
> difference is relatively significant nontheless.
> 
> cpu utlization on the sg interface was under 10%.  using 'dd' on the sd
> interface, both gigahertz P3 Xeons had 0% idle time.
> 


You need to be careful with this stuff.  Cache effects dominate.

I believe the /dev/sgX driver uses a fixed kernel-side buffer for
the transfer.  So the source of the copy_to_user() will always come
out of cache if the CPU is snooping the busmastering.  But not if
the CPU is performing cache invalidates in response to that busmastering.

But for `dd', which has to copy the data out of pagecache, the
copy_from_user() will get 100% misses on the source, guaranteed.

Also, the `sg_read' command reads everything into the same (small)
chunk of userspace memory.   So the destination of copy_to_user()
is always in cache.  Probably, the same is true with `dd bs=512',
but one would have to go read the dd source to verify.

This is also why the scsi_debug driver runs so much faster than normal
devices: it copies everything out of a fixed in-kernel buffer.  ie:
out of L1 cache.  Fast.

Similarly, `sg_dd' against scsi_debug is copying a fixed kernel buffer
into a fixed userspace buffer  But when `dd' tries to do the same thing
it incurs an additional copy into the pagecache.  If the pagecache
readahead window exceeds your L1 cache size (it does) then it will
appear to be a lot slower.

Summary: the block layer ain't slow - it's memory which is slow ;)

-

Re: [PATCH] 2.5.14 IDE 56

[Lincoln Dale]

At 08:10 PM 8/05/2002 -0700, Andrew Morton wrote:
> > whether the bottleneck was copy-from-kernel-to-userspace (ie. exhaustion of
> > Front-Side-Bus / memory bandwidth) or related to block-layer overhead and
> > scsi layer overheads, i haven't yet validated, but at a ~35% performance
> > difference is relatively significant nontheless.
>
>You need to be careful with this stuff.  Cache effects dominate.
...

i've validated that the performance difference is due to copy_to_user().
i created a hack in the tree where a read() on a file opened with the 
option O_NOCOPY causes no copy_to_user() to occur. (diff at the bottom of 
this email).

on this test machine (dual P3 Xeon / 256K L2 cache, 2G PC133 SDRAM, QLogic 
2300 FC HBA, 8 x 15K RPM disks).
maximum theoretical performance is 2gbit/s (~200mbyte/sec).  kernel is 2.4.18.

i get the following performance numbers with 256K reads syncronously from 
the disks:
         /dev/md0 raid-0 with O_DIRECT:          91847kbyte/sec (2781usec 
avg latency/read)
         /dev/md0 raid-0:                                129455kbyte/sec 
(1978usec avg latency/read)
         /dev/md0 raid-0 with O_NOCOPY:  195868kbyte/sec (1297usec avg 
latency/read)

         requests split evenly across /dev/sd[e-l] w/ O_DIRECT:
                                                 78279kbyte/sec (3276usec 
avg latency/read)
         requests split evenly across /dev/sd[e-l]:      105130kbyte/sec 
(2437usec avg latency/read)
         requests split evenly across /dev/sd[e-l] w/ O_NOCOPY:
                                                 123050kb/sec (2088usec avg 
latency/read)

there's some interesting numbers here.
  - given the performance difference between O_NOCOPY and pristine on
    /dev/md0 one can definitely point at that being the copy_to_user() 
overhead.
  - however, when requests are split across multiple block-devices 
(/dev/sd[e-l])
    the difference are significantly decreased -- and something wierdo is 
going on:
         - readahead?
         - scsi priorities?
    perhaps some form of async i/o is required to get the performance back.

i'll do some experiments with a 2.5.xx and see if the block-layer changes 
cause any significant changes.


         --- pristine/linux/include/asm-i386/fcntl.h     Tue Sep 18 
06:16:30 2001
         +++ linux/include/asm-i386/fcntl.h      Thu May  9 18:56:46 2002
         @@ -20,6 +20,7 @@
          #define O_LARGEFILE    0100000
          #define O_DIRECTORY    0200000 /* must be a directory */
          #define O_NOFOLLOW     0400000 /* don't follow links */
         +#define O_NOCOPY        04 /* LTD HACK: dont do copy_to_user */

          #define F_DUPFD                0       /* dup */
          #define F_GETFD                1       /* get close_on_exec */
         --- pristine/linux/mm/filemap.c Tue Feb 26 06:38:13 2002
         +++ linux/mm/filemap.c  Thu May  9 18:56:48 2002
         @@ -1544,6 +1544,19 @@
                 return retval;
          }

         +int file_read_nocopy_actor(read_descriptor_t * desc, struct page 
*page, unsigned long offset, unsigned long size)
         +{
         +       unsigned long count = desc->count;
         +
         +       if (size > count)
         +               size = count;
         +
         +       desc->count = count - size;
         +       desc->written += size;
         +       desc->buf += size;
         +       return size;
         +}
         +
          int file_read_actor(read_descriptor_t * desc, struct page *page, 
unsigned long offset, unsigned long size)
          {
                 char *kaddr;
@@ -1591,7 +1604,7 @@
                         desc.count = count;
                         desc.buf = buf;
                         desc.error = 0;
-                       do_generic_file_read(filp, ppos, &desc, 
file_read_actor);
+                       do_generic_file_read(filp, ppos, &desc, 
((filp->f_flags & O_NOCOPY) ? file_read_nocopy_actor : file_read_actor));

                         retval = desc.written;
                         if (!retval)

cheers,

lincoln.

Re: [PATCH] 2.5.14 IDE 56

[Andrew Morton]

Lincoln Dale wrote:
> 
> ...
> i've validated that the performance difference is due to copy_to_user().
> i created a hack in the tree where a read() on a file opened with the
> option O_NOCOPY causes no copy_to_user() to occur. (diff at the bottom of
> this email).
> 
> on this test machine (dual P3 Xeon / 256K L2 cache, 2G PC133 SDRAM, QLogic
> 2300 FC HBA, 8 x 15K RPM disks).
> maximum theoretical performance is 2gbit/s (~200mbyte/sec).  kernel is 2.4.18.
> 
> i get the following performance numbers with 256K reads syncronously from
> the disks:

For bulk read() and write() I/O the best sized buffer is 8 kbytes.  4k is
pretty good, too.  Anything larger blows the user-side buffer out of L1.
This is for x86.

This is a pretty important point, so let's repeat it:

Userspace programmers who are writing bulk-transfer read/write loops
should use an 8 kbyte transfer buffer.

>          /dev/md0 raid-0 with O_DIRECT:          91847kbyte/sec (2781usec
> avg latency/read)
>          /dev/md0 raid-0:                                129455kbyte/sec
> (1978usec avg latency/read)
>          /dev/md0 raid-0 with O_NOCOPY:  195868kbyte/sec (1297usec avg
> latency/read)

hmm.  Why is O_DIRECT always the slowest?  (and it would presumably do
even worse with an 8k transfer size).

-

Re: [PATCH] 2.5.14 IDE 56

[Andi Kleen]

Andrew Morton <akpm@zip.com.au> writes:

> For bulk read() and write() I/O the best sized buffer is 8 kbytes.  4k is
> pretty good, too.  Anything larger blows the user-side buffer out of L1.
> This is for x86.

Modern x86 support prefetch hints for the CPU to tell it to not 
pollute the caches with "streaming data". I bet using them would
be a big win. The rep ; movsl loop used in copy*user isn't 
very good on modern x86 anyways (it is ok on PPro, but loses on Athlon
and P4) 

I'm (slowly) working on such functions for x86-64, it should be eventually
possible to backport them to i386.

-Andi

Re: [PATCH] 2.5.14 IDE 56

[Andrew Morton]

Andi Kleen wrote:
> 
> Andrew Morton <akpm@zip.com.au> writes:
> 
> > For bulk read() and write() I/O the best sized buffer is 8 kbytes.  4k is
> > pretty good, too.  Anything larger blows the user-side buffer out of L1.
> > This is for x86.
> 
> Modern x86 support prefetch hints for the CPU to tell it to not
> pollute the caches with "streaming data". I bet using them would
> be a big win.

Maybe.  For your basic:

	for (many) {
		read(fd1, buf, 8192);
		write(fd2, buf, 8192);
	}

you want `buf' cached, but not the pagecache for fd1 and fd2.
If the prefetch hints can express that then yes, nice.

> The rep ; movsl loop used in copy*user isn't
> very good on modern x86 anyways (it is ok on PPro, but loses on Athlon
> and P4)

On PII and PIII, rep;movsl is slower than an open-coded
duff-device copy for all src/dest alignments except for
the case where both are eight-byte-aligned.  By up to
20%, iirc.  four-byte-aligned to four-byte-aligned isn't
too bad.

Of course, a lot of copy_*_users are well-aligned.  But
a lot are not.  I ended up deciding that switching to
the duff-device copy would be a very small overall win, when
you weight it by the alignment patterns of normal kernel
usage.

But making a runtime slection of which copy function to
use (based on src/dest alignment) could speed up the
kernel's most expensive function by maybe 10-15% overall.

The test proggy is in http://www.zip.com.au/~akpm/linux/cptimer.tar.gz


-

Re: [PATCH] 2.5.14 IDE 56

[Andi Kleen]

On Fri, May 10, 2002 at 02:48:15AM +0200, Andrew Morton wrote:
> Andi Kleen wrote:
> > 
> > Andrew Morton <akpm@zip.com.au> writes:
> > 
> > > For bulk read() and write() I/O the best sized buffer is 8 kbytes.  4k is
> > > pretty good, too.  Anything larger blows the user-side buffer out of L1.
> > > This is for x86.
> > 
> > Modern x86 support prefetch hints for the CPU to tell it to not
> > pollute the caches with "streaming data". I bet using them would
> > be a big win.
> 
> Maybe.  For your basic:
> 
> 	for (many) {
> 		read(fd1, buf, 8192);
> 		write(fd2, buf, 8192);
> 	}
> 
> you want `buf' cached, but not the pagecache for fd1 and fd2.
> If the prefetch hints can express that then yes, nice.

SSE has prefetchnta

3dnow has something similar.

In addition you can use movnti* for stores. These should be faster
because they use write combining and avoid the latency of fetching
the cache line of the destination just to overwrite it.

The tricky bit is to avoid prefetches over the boundary of your copy.
Prefetching from an uncached area or write combined area (like the 
AGP gart which could start in next page) triggers hardware bugs in
various boxes. This unfortunately complicates the prefetching loops
a bit.

> 
> > The rep ; movsl loop used in copy*user isn't
> > very good on modern x86 anyways (it is ok on PPro, but loses on Athlon
> > and P4)
> 
> On PII and PIII, rep;movsl is slower than an open-coded
> duff-device copy for all src/dest alignments except for
> the case where both are eight-byte-aligned.  By up to
> 20%, iirc.  four-byte-aligned to four-byte-aligned isn't
> too bad.

That's surprising. AFAIK on PPro rep ; movs does magic prefetch
tricks in microcode, so it should be eventually faster if you do
not use explicit prefetching and you're not cache hot for 
bigger copies (in smaller ones the setup overhead may dominate)

On Athlon rep ; movs loses clearly compared to an unrolled loop.

-Andi

Re: [PATCH] 2.5.14 IDE 56

[Pavel Machek]

Hi!

> The tricky bit is to avoid prefetches over the boundary of your copy.
> Prefetching from an uncached area or write combined area (like the 
> AGP gart which could start in next page) triggers hardware bugs in
> various boxes. This unfortunately complicates the prefetching loops
> a bit.

CONFIG_MY_MACHINE_AINT_BORKEN? We definitely could assume that on x86-64.

								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH] 2.5.14 IDE 56

[Andi Kleen]

On Mon, May 13, 2002 at 07:51:00PM +0200, Pavel Machek wrote:
> Hi!
> 
> > The tricky bit is to avoid prefetches over the boundary of your copy.
> > Prefetching from an uncached area or write combined area (like the 
> > AGP gart which could start in next page) triggers hardware bugs in
> > various boxes. This unfortunately complicates the prefetching loops
> > a bit.
> 
> CONFIG_MY_MACHINE_AINT_BORKEN? We definitely could assume that on x86-64.

I was advised by AMD that I should better avoid it even for future boxes.

-Andi

Re: [PATCH] 2.5.14 IDE 56

[Andre Hedrick]

Lincoln,

You are right on the money!
There is about 35-40% throughput killjoy "copy-from-kernel-to-userspace".
It is easy to demo if you have a bus analizer and can do accounting on the
data io less the command block overhead.

CR3's are your friend, not ...

On Thu, 9 May 2002, Lincoln Dale wrote:

> At 01:42 PM 8/05/2002 +0100, Alan Cox wrote:
> >The SCSI layer is significant overhead even in 2.5.
> 
> i did some benchmarking on a high-end dual P3 Xeon (Serverworks chipset ) 
> with QLogic 2300 (2gbit/s) 64/66 Fibre Channel controllers.
> 
> using the '/dev/sgX' interface to issue scsi reads/writes allowed me to hit 
> the magical limit of 200mbyte/sec throughput.  (basically just about 
> linerate).  (simultaneous "sg_read if=/dev/sgX mmap=1 bs=512 count=35M"; 
> sg_read from the sg-tools package)
> 
> doing the same test thru the block-layer was basically capped at around 
> 135mbyte/sec.  (simultaneous "dd if=/dev/sdX of=/dev/null bs=512 count=35M").
> 
> whether the bottleneck was copy-from-kernel-to-userspace (ie. exhaustion of 
> Front-Side-Bus / memory bandwidth) or related to block-layer overhead and 
> scsi layer overheads, i haven't yet validated, but at a ~35% performance 
> difference is relatively significant nontheless.
> 
> cpu utlization on the sg interface was under 10%.  using 'dd' on the sd 
> interface, both gigahertz P3 Xeons had 0% idle time.
> 
> 
> cheers,
> 
> lincoln.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> You are right on the money!
> There is about 35-40% throughput killjoy "copy-from-kernel-to-userspace".
> It is easy to demo if you have a bus analizer and can do accounting on the
> data io less the command block overhead.
> 
> CR3's are your friend, not ...

You should be able to verify that by using large O_DIRECT I/O's. The
block layer itself may well be part of the overhead. With the scsi layer,
the block->scsi handling code is definitely a bottleneck to performance

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> doing the same test thru the block-layer was basically capped at around 
> 135mbyte/sec.  (simultaneous "dd if=/dev/sdX of=/dev/null bs=512 count=35M").

Tweak your dd to use O_DIRECT and use an O_DIRECT capable fs - that tells
you if its copy overhead or disk side stuff.

Re: [PATCH] 2.5.14 IDE 56

[Erik Andersen]

On Wed May 08, 2002 at 01:18:47PM +0100, Alan Cox wrote:
> I can't speak directly for the Kudzu maintainer but I can say that having
> a sane way to obtain the list of ide devices (all of them not just non 
> pcmcia) and the device bindings/type has been a long standing request.

Can't one simply do something like:

char device_string[20];
int i, type, major=0, minor=0;
for(i=0; i<26; i++) {
    snprintf(device_string, sizeof(device_string), "/dev/hd%c", 'a'+i);
    if ((fd=open(device_string, O_RDONLY | O_NONBLOCK)) < 0) {
	continue;
    }
    switch ('a'+i) {
	case 'a':
	    major=3;minor=0;
	    break;
	case 'b':
	    major=3;minor=64;
	    break;
	case 'c':
	    major=22;minor=0;
	    break;
	case 'd':
	    major=22;minor=64;
	    break;
	.....
    }

etc.... to detect the available ide devices without groveling
through /proc/ide?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: [PATCH] 2.5.14 IDE 56

[Dave Jones]

On Wed, May 08, 2002 at 12:21:39PM -0600, Erik Andersen wrote:
 >     if ((fd=open(device_string, O_RDONLY | O_NONBLOCK)) < 0) {
 ...

 > etc.... to detect the available ide devices without groveling
 > through /proc/ide?

This goes splat with removable IDE devices like ZIP drives etc.
They fail to open() unless you put a disk in them.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> int i, type, major=0, minor=0;
> for(i=0; i<26; i++) {
>     snprintf(device_string, sizeof(device_string), "/dev/hd%c", 'a'+i);
>     if ((fd=open(device_string, O_RDONLY | O_NONBLOCK)) < 0) {
> 	continue;
>     }

If it opened is it there. Suppose its an IDE floppy and no media is 
present. Maybe its hiding in ide-scsi instead.  It ends up being detective
work. The /device set up makes it explicit and clean

Re: [PATCH] 2.5.14 IDE 56

[Erik Andersen]

On Wed May 08, 2002 at 08:31:11PM +0100, Alan Cox wrote:
> > int i, type, major=0, minor=0;
> > for(i=0; i<26; i++) {
> >     snprintf(device_string, sizeof(device_string), "/dev/hd%c", 'a'+i);
> >     if ((fd=open(device_string, O_RDONLY | O_NONBLOCK)) < 0) {
> > 	continue;
> >     }
> 
> If it opened is it there. Suppose its an IDE floppy and no media is 
> present. Maybe its hiding in ide-scsi instead.  It ends up being detective
> work. 

That suggests to me that IDE floppy needs to be fixed to open
even when no media is present when provided with the  O_NONBLOCK
flag, which would be consistant with how CDROMs, and everything
SCSI works.

As for ide-scsi, I thought that was going to go away?  

> work. The /device set up makes it explicit and clean

agreed.  But I don't expect to see that showing up soon in 2.4.x,
which is what most people (like me) will be using for the next
year or two.  Sure 2.5.x it might work, but it might eat your
disk too.  So is groping about in /proc/ide the only way to get
reliable ide device detection for 2.4.x, or is there some other
way?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: [PATCH] 2.5.14 IDE 56

[Alan Cox]

> That suggests to me that IDE floppy needs to be fixed to open
> even when no media is present when provided with the  O_NONBLOCK
> flag, which would be consistant with how CDROMs, and everything
> SCSI works.
> 
> As for ide-scsi, I thought that was going to go away?  

If we move to a more general device tree and you can set the mode you wish
to use when accessing the device it can do. Right now the "mode" so to
speak is implied by the file you open rather than by how you send it
commands and what you ask it to do

Re: [PATCH] 2.5.14 IDE 56

[Pavel Machek]

Hi!

> BTW. If one needs the size of the disk well we could
> attach it as a file size to the device file in /dev IMHO. Why not?

Seems like good idea. (I don't know how happy du is going to be that. OTOH
is du is not happy, we should fix it not to count block devices...)
								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH] 2.5.14 IDE 56

[Daniel Jacobowitz]

On Thu, May 09, 2002 at 01:13:42PM +0000, Pavel Machek wrote:
> Hi!
> 
> > BTW. If one needs the size of the disk well we could
> > attach it as a file size to the device file in /dev IMHO. Why not?
> 
> Seems like good idea. (I don't know how happy du is going to be that. OTOH
> is du is not happy, we should fix it not to count block devices...)
> 								Pavel

The number /usr/bin/du shows is the block usage, not the logical size;
you could use the logical size for this...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] 2.5.14 IDE 56

[Padraig Brady]

Martin Dalecki wrote:
> Uz.ytkownik Linus Torvalds napisa?:
> 
>> But there is definitely a potential backwards-compatibility-issue.
> 
> 
> Linus - there are no backward compatibility issues here.
> No single application from my system does mess with /proc/ide.
> They showed you a list of programs which use /proc and not a list
> of programs which use anything out of /proc/ide...

To be thorough, I greped for /proc/ide not just /proc,
the exact command was:

find /sbin /usr/sbin /bin /usr/bin /lib /usr/lib /usr/bin/X11/ -xdev 
-perm +111 | xargs grep -l /proc/ide 2>/dev/null

Padraig.

Re: [PATCH] 2.5.14 IDE 56

[Pavel Machek]

Hi!

> 	/driverfs/root/pci0/00:1f.4/usb_bus/000/
> 
> and it wouldn't be impossible (or even necessarily very hard) to make an
> IDE controller export the "IDE device tree" the same way a USB controller
> now exports the "USB device tree".

Look harder, it should be already there.
 								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH] 2.5.14 IDE 56

[Richard B. Johnson]

On Tue, 7 May 2002, Padraig Brady wrote:

> Linus Torvalds wrote:
> >  [ First off: any IDE-only thing that doesn't work for SCSI or other disks
> >    doesn't solve a generic problem, so the complaint that some generic
> >    tools might use it is totally invalid. ]
> > 
> > On Tue, 7 May 2002, Anton Altaparmakov wrote:
> > 
> >>Linux's power is exactly that it can be used on anything from a wristwatch
> >>to a huge server and that it is flexible about everything. You are breaking
> >>this flexibility for no apparent reason. (I don't accept "I can't cope with
> >>this so I remove it." as a reason, sorry).
> > 
> > 
> > Run the 57 patch, and complain if something doesn't work.
> > 
> > Linux's power is that we FIX stuff. That we make it the best system
> > possible, and that we don't just whine and argue about things.
> > 
> > 
> >>As the new IDE maintainer so far we have only seen you removing one
> >>feature after the other in the name of cleanup, without adequate or even
> >>any at all(!) replacements,
> > 
> > 
> > Who cares? Have you found _anything_ that Martin removed that was at all
> > worthwhile? I sure haven't.
> > 
> > Guys, you have to realize that the IDE layer has eight YEARS of absolute
> > crap in it. Seriously. It's _never_ been cleaned up before. It has stuff
> > so distasteful that t's scary.
> > 
> > Take it from me: it's a _lot_ easier to add cruft and crap on top of clean
> > code. You can do it yourself if you want to. You don't need a maintainer
> > to add barnacles.
> > 
> > All the information that /proc/ide gave you is basically available in
> > hdparm, and for your dear embedded system it apparently takes up less
> > space by being in user space. So what is the problem?
> 
> Well my "dear" embedded system doesn't have libc :-(
> So 35664 saved in kernel (less on disk), requires 25212
> extra for hdparm + more for static linked uclibc (hope
> it works ;-)). As a side note if this happens hdparm would
> be a requirement for busybox IMHO, anyway getting back on topic...

Link your embeded stuff against a stripped-down shared libc...

-rwxr-xr-x   1 root     root          876 Apr 26 13:08 crt1.o
-rwxr-xr-x   1 root     root       160824 Feb 25 13:30 ld-linux.so.2
-rwxr-xr-x   1 root     root       160824 Apr 30 11:31 ld.so
-rwxr-xr-x   1 root     root      2376745 Feb 25 13:29 libc.so.6
-rwxr-xr-x   1 root     root       368551 Feb 25 13:29 libm.so.6

This does most everything an embedded system needs. You can extract
the objects from a shared object file (copy), remove the ones you
obviously don't need, make a new shared object file and link. Keep
adding objects until you don't have a any more unresolved symbols.

`ld` allows you to link to whatever you need. I put my special
'libc' plus another private shared library in /opt/lib. On the
target machine, /opt/lib is a sym-link to /lib.

LPATH=/opt/lib
ELINK=-rpath-link $(LPATH) \
 -rpath $(LPATH) \
 -L $(LPATH) -m elf_i386 \
 -dynamic-linker \
 $(LPATH)/ld-linux.so.2 \
 $(LPATH)/crt1.o \
 $(LPATH)/crtendS.o \
 $(LPATH)/libc.so.6 \
 $(LPATH)/libm.so.6


program:	program.o
		ld -o program program.o $(ELINK)


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: [PATCH] 2.5.14 IDE 56

[Martin Dalecki]

Uz.ytkownik Padraig Brady napisa?:
> Linus Torvalds wrote:
> 
>>  [ First off: any IDE-only thing that doesn't work for SCSI or other 
>> disks
>>    doesn't solve a generic problem, so the complaint that some generic
>>    tools might use it is totally invalid. ]
>>
>> On Tue, 7 May 2002, Anton Altaparmakov wrote:
>>
>>> Linux's power is exactly that it can be used on anything from a 
>>> wristwatch
>>> to a huge server and that it is flexible about everything. You are 
>>> breaking
>>> this flexibility for no apparent reason. (I don't accept "I can't 
>>> cope with
>>> this so I remove it." as a reason, sorry).
>>
>>
>>
>> Run the 57 patch, and complain if something doesn't work.
>>
>> Linux's power is that we FIX stuff. That we make it the best system
>> possible, and that we don't just whine and argue about things.
>>
>>
>>> As the new IDE maintainer so far we have only seen you removing one
>>> feature after the other in the name of cleanup, without adequate or even
>>> any at all(!) replacements,
>>
>>
>>
>> Who cares? Have you found _anything_ that Martin removed that was at all
>> worthwhile? I sure haven't.
>>
>> Guys, you have to realize that the IDE layer has eight YEARS of absolute
>> crap in it. Seriously. It's _never_ been cleaned up before. It has stuff
>> so distasteful that t's scary.
>>
>> Take it from me: it's a _lot_ easier to add cruft and crap on top of 
>> clean
>> code. You can do it yourself if you want to. You don't need a maintainer
>> to add barnacles.
>>
>> All the information that /proc/ide gave you is basically available in
>> hdparm, and for your dear embedded system it apparently takes up less
>> space by being in user space. So what is the problem?
> 
> 
> Well my "dear" embedded system doesn't have libc :-(
> So 35664 saved in kernel (less on disk), requires 25212
> extra for hdparm + more for static linked uclibc (hope
> it works ;-)). As a side note if this happens hdparm would
> be a requirement for busybox IMHO, anyway getting back on topic...
> 
> All the info I've ever needed is /proc/ide/hdx/capacity
> which I could get from /proc/partitions with more a bit
> more effort, so I vote for removing /proc/ide.
> 
> I think everyone realises Martin is doing great and much needed work
> on IDE (btw I'll have those flash support patches soon Martin ;-)),
> but I did think this change needed debate. In general I know it's a
> hard decision what to export in proc, especially if there are
> existing dependencies, a few already mentioned possibles in RH7.1:
> 
> /sbin/mkinitrd
> /sbin/fdisk
> /sbin/sfdisk
> /sbin/sndconfig
> /usr/sbin/mouseconfig
> /usr/sbin/kudzu
> /usr/sbin/module_upgrade
> /usr/sbin/updfstab
> /usr/sbin/glidelink
> /usr/sbin/sndconfig
> /usr/lib/python1.5/site-packages/_kudzumodule.so
> /usr/bin/X11/Xconfigurator
> 
> For e.g. could the same arguments could be made for lspci only
> interface to pci info rather than /proc/bus/pci? The following
> references are made to /proc/bus/pci on my system:

In esp. in sigth of the fact that we have a device tree filesystem, I
rather think that /prco/bus/pci is obsolete indeed.

Re: [PATCH] 2.5.14 IDE 56

[Greg KH]

On Wed, May 08, 2002 at 09:36:27AM +0200, Martin Dalecki wrote:
> >
> >For e.g. could the same arguments could be made for lspci only
> >interface to pci info rather than /proc/bus/pci? The following
> >references are made to /proc/bus/pci on my system:
> 
> In esp. in sigth of the fact that we have a device tree filesystem, I
> rather think that /prco/bus/pci is obsolete indeed.

Not quite yet.  I considered moving the functionality of /proc/bus/pci
into driverfs, but couldn't find a good solid reason to do it (and it
would involve changing lspci and any other userspace programs that use
it today.)

Now reimplementing /proc/bus/pci as a stand alone filesystem mounted in
that position (like usbfs is) is another story.  pcifs anyone?  :)

thanks,

greg k-h

Re: [PATCH] 2.5.14 IDE 56

[Denis Vlasenko]

On 7 May 2002 09:22, Martin Dalecki wrote:
> Mon May  6 13:29:44 CEST 2002 ide-clean-56

+	printk("%s: reset timed-out, status=0x%02x\n", ch->name, stat);

"timed out" (no dash)
--
vda