Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[James Bottomley]

    Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
    and SCSI cdbs to a device.  (for the uninitiated, this is lower level
    than block devices / cdrom devices / etc.)
    
     ... AF_BLOCK is not out of the question ;-)
    
    
Well, I think the main issue to doing this is one of layering.  What
SAM-3 did for SCSI was essentially give us a 3 layer stack which the
kernel represents as the upper, the mid and the lower layers  (Note,
these layers are subdividable too).

For SCSI commands, queuecommand() is a natural handoff point from the
mid to lower layer representing a pure scsi command with no transport
dependent details.

For ATA, a task file does contain transport dependent knowledge, thus it
should enter the stack at a slightly lower level (and a level which the
current SCSI model doesn't even represent).

Thus, the two ways of approaching this would seem to be either to derive
somehow a way of removing the transport dependence from the taskfile (a
sort of Task CDB for ATA), or redo the driver model stack to subdivide
the current low level drivers correctly.  I think the latter will
probably be more productive, particularly if the subdivision is made
optional (and thus wouldn't affect most of the drivers currently in the
tree).  Even in SCSI, there are certain register based SCSI Parallel
cards that would benefit from being driven at the same level as a task
file.

James

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

On Sat, Sep 13, 2003 at 03:16:09PM -0500, James Bottomley wrote:
> 
>     Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
>     and SCSI cdbs to a device.  (for the uninitiated, this is lower level
>     than block devices / cdrom devices / etc.)
>     
>      ... AF_BLOCK is not out of the question ;-)
>     
>     
> Well, I think the main issue to doing this is one of layering.  What
> SAM-3 did for SCSI was essentially give us a 3 layer stack which the
> kernel represents as the upper, the mid and the lower layers  (Note,
> these layers are subdividable too).
> 
> For SCSI commands, queuecommand() is a natural handoff point from the
> mid to lower layer representing a pure scsi command with no transport
> dependent details.
> 
> For ATA, a task file does contain transport dependent knowledge, thus it
> should enter the stack at a slightly lower level (and a level which the
> current SCSI model doesn't even represent).

This is a good point, and I admit I don't have a good response.

On one hand, the current kernel interface presented to userland is
the same for ATA and SCSI:  "an ioctl, which sends packet to device"
So from the standpoint of the userland ABI, that rebuts layering to
a certain extent.  We even have ioctls in today's ATA layer to send
SCSI CDBs to ATA devices!  ;-)

So from that angle, it all looks like a packet to me.
Or struct request, shall I say.  or skb.  after a while they are all the
same to me...


> Thus, the two ways of approaching this would seem to be either to derive
> somehow a way of removing the transport dependence from the taskfile (a
> sort of Task CDB for ATA), or redo the driver model stack to subdivide
> the current low level drivers correctly.  I think the latter will
> probably be more productive, particularly if the subdivision is made
> optional (and thus wouldn't affect most of the drivers currently in the
> tree).  Even in SCSI, there are certain register based SCSI Parallel
> cards that would benefit from being driven at the same level as a task
> file.

"the latter" is what I'm shooting for, with /dev/disk.  Or maybe
a better moniker is storage API.  I think that parallels a theme I am
pursuing in 2.7:

Make the low-level driver interface for ATA devices, RAID devices
like cciss, etc. look strikingly similar to the SCSI low-level driver
interface.  At that point we call it the "storage LLD interface".
This would IMO encompass the low-level driver subdivision you describe.

Ideally an ata/scsi/raid driver shouldn't be doing much more than
h/w queue processing, and some hooks for unusual events like power
management or h/w-specific device enumeration.

Overall I'd like to get "low level drivers" at pretty much the same
level.  ATA and SCSI drivers would be fairly small, with a lot of their
functionality handled by helper functions.  RAID drivers would be
largers.

Another thorny tangent to throw out there:

IMO, we need to move users from a [probe-]order-based device and bus
enumeration to some system based on unique ids.  I'm of the opinion
that _both_ block devices and filesystems need some sort of GUID.
Luckily, a lot of blkdevs/fs's are already there.

If you look at current usage out there, order isn't _terribly_ important
given today's tools (such as LABEL=).  More important IMO is figuring
out which spindle is your boot disk, and which is your root disk.
Red Hat handles root disks by doing LABEL= from initrd.  But discovering
the boot disk is still largely an unsolved problem AFAIK...

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Justin Cormack]

On Sat, 2003-09-13 at 22:27, Jeff Garzik wrote:

> IMO, we need to move users from a [probe-]order-based device and bus
> enumeration to some system based on unique ids.  I'm of the opinion
> that _both_ block devices and filesystems need some sort of GUID.
> Luckily, a lot of blkdevs/fs's are already there.
> 
> If you look at current usage out there, order isn't _terribly_ important
> given today's tools (such as LABEL=).  More important IMO is figuring
> out which spindle is your boot disk, and which is your root disk.
> Red Hat handles root disks by doing LABEL= from initrd.  But discovering
> the boot disk is still largely an unsolved problem AFAIK...

LABEL= is so broken that I immediately remove it from all my redhat
systems. It is not unique at all. As soon as you plug another system
disk into your system at boot time all hell breaks loose. At least it
could have a random number in it or something.

If you need to know your bootdisk (why?) why not just get the bootloader
to tell you?

Justin

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Alan Cox]

On Sul, 2003-09-14 at 12:15, Justin Cormack wrote:
> LABEL= is so broken that I immediately remove it from all my redhat
> systems. It is not unique at all. As soon as you plug another system
> disk into your system at boot time all hell breaks loose. At least it
> could have a random number in it or something.

You can use UUID's for labels too if you prefer. I normally write a 
host string into my labels. What I actually want is mount by label to
develop an rpc service so I can mount by label and if the disk is in
another box NFS it 8)

> If you need to know your bootdisk (why?) why not just get the bootloader
> to tell you?

The bootloader doesn't know. It has a bios concept of the boot device
which is really hard if at all possible to translate without things like
EDD.

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Kevin P. Fleming]

Alan Cox wrote:
> You can use UUID's for labels too if you prefer. I normally write a 
> host string into my labels. What I actually want is mount by label to
> develop an rpc service so I can mount by label and if the disk is in
> another box NFS it 8)

Sounds yummy! When can we start testing it? <G>

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Andries Brouwer]

On Sun, Sep 14, 2003 at 12:15:27PM +0100, Justin Cormack wrote:

> LABEL= is so broken that I immediately remove it from all my redhat
> systems. It is not unique at all. As soon as you plug another system
> disk into your system at boot time all hell breaks loose. At least it
> could have a random number in it or something.

I do not understand your complaint.
It is you who assigns the label. You can choose whatever label you fancy.
Include any random strings you like.

> If you need to know your bootdisk (why?) why not just get the bootloader
> to tell you?

I am not quite sure why anybody would like to know what the bootdisk was.
The rootdisk, yes, that we need. But the bootdisk?
Finding it is nontrivial in general. Letting the bootloader tell us
is also nontrivial.

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

Andries Brouwer wrote:
> On Sun, Sep 14, 2003 at 12:15:27PM +0100, Justin Cormack wrote:
>>If you need to know your bootdisk (why?) why not just get the bootloader
>>to tell you?

> I am not quite sure why anybody would like to know what the bootdisk was.
> The rootdisk, yes, that we need. But the bootdisk?
> Finding it is nontrivial in general. Letting the bootloader tell us
> is also nontrivial.

The bootloader or mkinitrd typically tells the kernel what the root disk 
is, so that's not a big deal.  The boot disk, OTOH, is tough.  Right 
now, we just assume the sysadmin knows what's he's doing, when he 
installs lilo or grub on a disk.  You care about the boot disk when 
installing lilo... maybe there are similar situations too which I do not 
recall.  As Alan said, besides EDD (only on newer boxes) there's really 
nothing.

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Alan Cox]

On Sul, 2003-09-14 at 18:01, Andries Brouwer wrote:
> I do not understand your complaint.

I sort of do - several vendor installers use fixed labels so
two installs on the same box get very confused. I've seen
novices tie themselves in knots with it before. That isn't
a problem with LABEL=, its an implementation issue with the
vendors install tools, and Red Hat certainly is one of the
parties that made this mistake.

Alan

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Thomas Molina]

On Sun, 14 Sep 2003, Alan Cox wrote:

> On Sul, 2003-09-14 at 18:01, Andries Brouwer wrote:
> > I do not understand your complaint.
> 
> I sort of do - several vendor installers use fixed labels so
> two installs on the same box get very confused. I've seen
> novices tie themselves in knots with it before. That isn't
> a problem with LABEL=, its an implementation issue with the
> vendors install tools, and Red Hat certainly is one of the
> parties that made this mistake.

LABEL= is the wrong solution to the right problem, IMHO.  It only seems to 
make sense if you are a distributor trying to make a one size mostly fits 
all.  If you tinker with your system it only seems to get in the way.  

It seems to me that if you are in the position of tinkering, and 
installing an OS you ought to have an understanding of root and boot 
disks, and what is in your system.  If you don't understand things well 
enough to specify the proper boot disk and root disk you shouldn't be 
tinkering and it won't matter how each is specified.

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Alan Cox]

On Maw, 2003-09-16 at 03:38, Thomas Molina wrote:
> It seems to me that if you are in the position of tinkering, and 
> installing an OS you ought to have an understanding of root and boot 
> disks, and what is in your system.  If you don't understand things well 
> enough to specify the proper boot disk and root disk you shouldn't be 
> tinkering and it won't matter how each is specified.

Your root disk can change for all sorts of non Linux reasons ranging
from windows config changes to hotplug devices. For example if your root
is /dev/sdc and /dev/sdb fails you'll want LABEL=.

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

Justin Cormack wrote:
> LABEL= is so broken that I immediately remove it from all my redhat
> systems. It is not unique at all. As soon as you plug another system
> disk into your system at boot time all hell breaks loose.

That's your fault as a sysadmin ;-)

> At least it
> could have a random number in it or something.

You can use UUIDs today!  :)


> If you need to know your bootdisk (why?) why not just get the bootloader
> to tell you?

The only time one cares what the boot disk is, is when _installing_ the 
boot loader...

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Andries Brouwer]

On Sat, Sep 13, 2003 at 05:27:23PM -0400, Jeff Garzik wrote:

> IMO, we need to move users from a [probe-]order-based device and bus
> enumeration to some system based on unique ids.  I'm of the opinion
> that _both_ block devices and filesystems need some sort of GUID.
> Luckily, a lot of blkdevs/fs's are already there.
> 
> If you look at current usage out there, order isn't _terribly_ important
> given today's tools (such as LABEL=).  More important IMO is figuring
> out which spindle is your boot disk, and which is your root disk.
> Red Hat handles root disks by doing LABEL= from initrd.  But discovering
> the boot disk is still largely an unsolved problem AFAIK...

Such things are infinitely difficult.
Moreover, great care is needed - one has to define precisely what it
is this GUID is supposed to be an ID of.

(Is it the ZIP drive? Or is it the ZIP disk?
The 2.4 USB code is broken because it remembers a GUID and thinks that
identical GUID implies identical disk.)

I have a handful of CF/SM cardreaders.
Some of them have no form of ID. Others have an ID.

Then one can insert a CF or SM card into the reader.
Some of these cards have an ID. Some have not.

On the card one usually finds a FAT filesystem.
There may be a label. Or there may not be.

This describes a 3-level situation.
I have also 4-level situations, where the reader is filled with
one of four auxiliary adapters (each with an own ID) and the
adapter then get a CF/SM/SD/... card.

So, yes, we love IDs. And we can always provide them ourselves
as label or UUID or so in the filesystem.

But finding an unformatted unlabeled disk is difficult.

Andries

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

Andries Brouwer wrote:
> Such things are infinitely difficult.
> Moreover, great care is needed - one has to define precisely what it
> is this GUID is supposed to be an ID of.

Absolutely agreed.


> (Is it the ZIP drive? Or is it the ZIP disk?
> The 2.4 USB code is broken because it remembers a GUID and thinks that
> identical GUID implies identical disk.)
> 
> I have a handful of CF/SM cardreaders.
> Some of them have no form of ID. Others have an ID.
> 
> Then one can insert a CF or SM card into the reader.
> Some of these cards have an ID. Some have not.
> 
> On the card one usually finds a FAT filesystem.
> There may be a label. Or there may not be.
> 
> This describes a 3-level situation.
> I have also 4-level situations, where the reader is filled with
> one of four auxiliary adapters (each with an own ID) and the
> adapter then get a CF/SM/SD/... card.

Using an adapter's ID would be a mistake.  You want to use the media's 
unique ID, assuming it has one.


> So, yes, we love IDs. And we can always provide them ourselves
> as label or UUID or so in the filesystem.

Not all filesystems have them :)

Further, some sites may prefer block-level GUIDs to fs-level ones. 
Sites using raw partitions instead of filesystems, for one.

We must leave this up to the sysadmin -- within the bounds of technology 
of course.  The sysadmin is out of luck if they purchase a media that 
does not support some sort of labelling or UUID.


> But finding an unformatted unlabeled disk is difficult.

You sound like you're agreeing with me ;-)

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Matt Domsch]

>    Further, some sites may prefer block-level GUIDs to fs-level ones.
>    Sites using raw partitions instead of filesystems, for one.

The EFI GUID Partition scheme (aka GPT aka CONFIG_EFI_PARTITION)
stores a GUID in the disk label to define the whole disk, plus another
per-partition GUID and per-partition label.  So even if the file
system doesn't have one, if you're using GPT, one *could* use those.
I haven't hacked up mount to search for those though.  If there's
enough interest, I'll do so.  Recall GPT is currently only used on
ia64, though the code works fine on other arches including x86, and
it's been decided (on l-k at least) that GPT will be the default disk
label format for systems running 2.6.x kernels with disks >2TB, as the
msdos label can't hold it.

> The boot disk, OTOH, is tough. Right now, we just assume the
> sysadmin knows what's he's doing, when he installs lilo or grub on a
> disk.  You care about the boot disk when installing lilo... maybe
> there are similar situations too which I do not recall.  As Alan
> said, besides EDD (only on newer boxes) there's really nothing.

EDD BIOSs are coming, slowly...  2 work today correctly, several more
are "close but no cigar", it's all the rest that worry me.

There's one more trick that's being used successfully, which I would
like to add to the EDD code.  That's "let BIOS help you out before
installing".  i.e. you boot into a FreeDOS environment, write a
system-unique disk signature to the boot disk (int13 device 80h)
"BOOT" or something - we've got 4 bytes available in the msdos label
for it, then reboot and let Linux go grab the signature,
store it, and like edd.o does, export it to userspace.  Now from
userspace one can see what Linux-named-disk has the signature you're
looking for, and voila, you now solved it w/o needing EDD BIOSs.  But
it requires a non-Linux boot step somewhere in the install process.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Alan Cox]

On Sad, 2003-09-13 at 17:11, Matt Domsch wrote:
> system-unique disk signature to the boot disk (int13 device 80h)
> "BOOT" or something - we've got 4 bytes available in the msdos label
> for it

int 13 is still available during the 16bit boot up phase of the kernel.
It does strike me as playing with fire, but an alternative approach
might work. Read the first 4K off the boot disk, stuff it somewhere 
temporary and then in 32bit compare it with the disk starts..

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Matt Domsch]

On Sun, Sep 14, 2003 at 05:26:54PM -0500, Alan Cox wrote:
>    On Sad, 2003-09-13 at 17:11, Matt Domsch wrote:
>    > system-unique disk signature to the boot disk (int13 device 80h)
>    > "BOOT" or something - we've got 4 bytes available in the msdos label
>    > for it
> 
>    int 13 is still available during the 16bit boot up phase of the kernel.
>    It does strike me as playing with fire, but an alternative approach
>    might work. Read the first 4K off the boot disk, stuff it somewhere
>    temporary and then in 32bit compare it with the disk starts..

This is essentially what we are proposing, only instead of reading 4K,
read 1 sector and stash the 4-byte disk signature where we can get at
it later, and export it via edd.o for comparison later.  This much is
easy, as the empty_zero_page has 512 bytes free for reading the sector
in setup.S, and 4 bytes we can use to stash the signature until
setup.c runs where we can copy it somewhere safe.  Then export it via
edd.o through /proc (2.4) or /sys (2.6).

The thing that writes the signature to disk can be anything that can
issue int13 calls.  Right now we do it in a FreeDOS app, but a special
loadlin/syslinux/isolinux used for OS installation may be simpler and
not require a FreeDOS environment be run ever.

-Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Matt Domsch]

On Sun, Sep 14, 2003 at 05:26:54PM -0500, Alan Cox wrote:
>    On Sad, 2003-09-13 at 17:11, Matt Domsch wrote:
>    > system-unique disk signature to the boot disk (int13 device 80h)
>    > "BOOT" or something - we've got 4 bytes available in the msdos label
>    > for it
> 
>    int 13 is still available during the 16bit boot up phase of the kernel.
>    It does strike me as playing with fire, but an alternative approach
>    might work. Read the first 4K off the boot disk, stuff it somewhere
>    temporary and then in 32bit compare it with the disk starts..

This is what I had in mind.
linux-2.4.23-pre4
+ http://domsch.com/linux/edd30/linux/linux-2.4.23-pre4-edd-20030914.patch.gz
+ patch below

 Documentation/i386/zero-page.txt |    4 +++-
 arch/i386/boot/setup.S           |   21 +++++++++++++++++++++
 arch/i386/kernel/edd.c           |   27 +++++++++++++++++++++++++--
 arch/i386/kernel/i386_ksyms.c    |    1 +
 arch/i386/kernel/setup.c         |    3 +++
 include/asm-i386/edd.h           |    7 ++++++-
 6 files changed, 59 insertions(+), 4 deletions(-)

This puts the 4-byte disk signature into
/proc/bios/edd/int13_dev80/mbr_signature

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com


diff -Nru a/Documentation/i386/zero-page.txt b/Documentation/i386/zero-page.txt
--- a/Documentation/i386/zero-page.txt	Mon Sep 15 17:00:58 2003
+++ b/Documentation/i386/zero-page.txt	Mon Sep 15 17:00:58 2003
@@ -66,8 +66,10 @@
 0x21c	unsigned long	INITRD_SIZE, size in bytes of ramdisk image
 0x220	4 bytes		(setup.S)
 0x224	unsigned short	setup.S heap end pointer
+0x228	4 bytes		DISK80_SIG_BUFFER (setup.S)
 0x2d0 - 0x600		E820MAP
-0x600 - 0x7D4		EDDBUF (setup.S)
+0x600 - 0x800		EDDBUF (setup.S) for disk signature read sector
+0x600 - 0x7d4		EDDBUF (setup.S)
 
 0x800	string, 2K max	COMMAND_LINE, the kernel commandline as
 			copied using CL_OFFSET.
diff -Nru a/arch/i386/boot/setup.S b/arch/i386/boot/setup.S
--- a/arch/i386/boot/setup.S	Mon Sep 15 17:00:58 2003
+++ b/arch/i386/boot/setup.S	Mon Sep 15 17:00:58 2003
@@ -49,6 +49,8 @@
  * by Matt Domsch <Matt_Domsch@dell.com> October 2002
  * conformant to T13 Committee www.t13.org
  *   projects 1572D, 1484D, 1386D, 1226DT
+ * disk signature read by Matt Domsch <Matt_Domsch@dell.com>
+ *	and Andrew Wilks <Andrew_Wilks@dell.com> September 2003
  */
 
 #include <linux/config.h>
@@ -549,6 +551,25 @@
 #endif
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
+# Read the first sector of device 80h and store the 4-byte signature
+	movl	$0xFFFFFFFF, %eax
+	movl	%eax, (DISK80_SIG_BUFFER)	# assume failure
+	movb	$READ_SECTORS, %ah
+	movb	$1, %al				# read 1 sector
+	movb	$0x80, %dl			# from device 80
+	movb	$0, %dh				# at head 0
+	movw	$1, %cx				# cylinder 0, sector 0
+	pushw	%es
+	pushw	%ds
+	popw	%es
+	movw	$EDDBUF, %bx
+	int	$0x13
+	jc	disk_sig_done
+	movl	(EDDBUF+MBR_SIG_OFFSET), %eax
+	movl	%eax, (DISK80_SIG_BUFFER)	# store success
+disk_sig_done:
+	popw	%es
+
 # Do the BIOS Enhanced Disk Drive calls
 # This consists of two calls:
 #    int 13h ah=41h "Check Extensions Present"
diff -Nru a/arch/i386/kernel/edd.c b/arch/i386/kernel/edd.c
--- a/arch/i386/kernel/edd.c	Mon Sep 15 17:00:58 2003
+++ b/arch/i386/kernel/edd.c	Mon Sep 15 17:00:58 2003
@@ -1,7 +1,8 @@
 /*
  * linux/arch/i386/kernel/edd.c
- *  Copyright (C) 2002 Dell Computer Corporation
+ *  Copyright (C) 2002, 2003 Dell, Inc.
  *  by Matt Domsch <Matt_Domsch@dell.com>
+ *  disk80 signature by Matt Domsch, Andrew Wilks, and Sandeep K. Shandilya
  *
  * BIOS Enhanced Disk Drive Services (EDD)
  * conformant to T13 Committee www.t13.org
@@ -27,7 +28,6 @@
 /*
  * TODO:
  * - move edd.[ch] to better locations if/when one is decided
- * - keep current with 2.5 EDD code changes
  */
 
 #include <linux/module.h>
@@ -333,6 +333,18 @@
 }
 
 static int
+edd_show_disk80_sig(char *page, char **start, off_t off, int count, int *eof, void *data)
+{
+	char *p = page;
+	if ( !page || off) {
+		return proc_calc_metrics(page, start, off, count, eof, 0);
+	}
+
+	p += snprintf(p, left, "0x%08x\n", edd_disk80_sig);
+	return proc_calc_metrics(page, start, off, count, eof, (p - page));
+}
+
+static int
 edd_show_extensions(char *page, char **start, off_t off, int count, int *eof, void *data)
 {
 	struct edd_info *info = data;
@@ -491,6 +503,15 @@
 	return 1;
 }
 
+static int
+edd_has_disk80_sig(struct edd_device *edev)
+{
+	struct edd_info *info = edd_dev_get_info(edev);
+	if (!edev || !info)
+		return 0;
+	return info->device == 0x80;
+}
+
 static EDD_DEVICE_ATTR(raw_data, edd_show_raw_data, NULL);
 static EDD_DEVICE_ATTR(version, edd_show_version, NULL);
 static EDD_DEVICE_ATTR(extensions, edd_show_extensions, NULL);
@@ -505,6 +526,7 @@
 		       edd_has_default_sectors_per_track);
 static EDD_DEVICE_ATTR(interface, edd_show_interface,edd_has_edd30);
 static EDD_DEVICE_ATTR(host_bus, edd_show_host_bus, edd_has_edd30);
+static EDD_DEVICE_ATTR(mbr_signature, edd_show_disk80_sig, edd_has_disk80_sig);
 
 static struct edd_attribute *def_attrs[] = {
 	&edd_attr_raw_data,
@@ -517,6 +539,7 @@
 	&edd_attr_default_sectors_per_track,
 	&edd_attr_interface,
 	&edd_attr_host_bus,
+	&edd_attr_mbr_signature,
 	NULL,
 };
 
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c	Mon Sep 15 17:00:58 2003
+++ b/arch/i386/kernel/i386_ksyms.c	Mon Sep 15 17:00:58 2003
@@ -185,4 +185,5 @@
 #ifdef CONFIG_EDD_MODULE
 EXPORT_SYMBOL(edd);
 EXPORT_SYMBOL(eddnr);
+EXPORT_SYMBOL(edd_disk80_sig);
 #endif
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c	Mon Sep 15 17:00:58 2003
+++ b/arch/i386/kernel/setup.c	Mon Sep 15 17:00:58 2003
@@ -212,6 +212,7 @@
 #define KERNEL_START (*(unsigned long *) (PARAM+0x214))
 #define INITRD_START (*(unsigned long *) (PARAM+0x218))
 #define INITRD_SIZE (*(unsigned long *) (PARAM+0x21c))
+#define DISK80_SIGNATURE (*(unsigned int*) (PARAM+DISK80_SIG_BUFFER))
 #define EDD_NR     (*(unsigned char *) (PARAM+EDDNR))
 #define EDD_BUF     ((struct edd_info *) (PARAM+EDDBUF))
 #define COMMAND_LINE ((char *) (PARAM+2048))
@@ -721,6 +722,7 @@
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
 unsigned char eddnr;
 struct edd_info edd[EDDMAXNR];
+unsigned int edd_disk80_sig;
 /**
  * copy_edd() - Copy the BIOS EDD information
  *              from empty_zero_page into a safe place.
@@ -730,6 +732,7 @@
 {
      eddnr = EDD_NR;
      memcpy(edd, EDD_BUF, sizeof(edd));
+     edd_disk80_sig = DISK80_SIGNATURE;
 }
 #else
 static inline void copy_edd(void) {}
diff -Nru a/include/asm-i386/edd.h b/include/asm-i386/edd.h
--- a/include/asm-i386/edd.h	Mon Sep 15 17:00:58 2003
+++ b/include/asm-i386/edd.h	Mon Sep 15 17:00:58 2003
@@ -1,6 +1,6 @@
 /*
  * linux/include/asm-i386/edd.h
- *  Copyright (C) 2002 Dell Computer Corporation
+ *  Copyright (C) 2002, 2003 Dell, Inc.
  *  by Matt Domsch <Matt_Domsch@dell.com>
  *
  * structures and definitions for the int 13h, ax={41,48}h
@@ -41,6 +41,10 @@
 #define EDDMAGIC1 0x55AA
 #define EDDMAGIC2 0xAA55
 
+#define READ_SECTORS 0x02
+#define MBR_SIG_OFFSET 0x1B8
+#define DISK80_SIG_BUFFER 0x228
+
 #ifndef __ASSEMBLY__
 
 #define EDD_EXT_FIXED_DISK_ACCESS           (1 << 0)
@@ -167,6 +171,7 @@
 
 extern struct edd_info edd[EDDMAXNR];
 extern unsigned char eddnr;
+extern unsigned int edd_disk80_sig;
 #endif				/*!__ASSEMBLY__ */
 
 #endif				/* _ASM_I386_EDD_H */

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Andre Hedrick]

Matt:

This would require the generic mapping of disc labels away from the
current hdX/sdX to hdN where 0 =< N < 5.  This issue will be mapping EDDS
which you are working on, and I tip my hat for what value it has left.

I will chat offline more in details to see where you are going and if I
can offer help from the T13 side of life.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 13 Sep 2003, Matt Domsch wrote:

> >    Further, some sites may prefer block-level GUIDs to fs-level ones.
> >    Sites using raw partitions instead of filesystems, for one.
> 
> The EFI GUID Partition scheme (aka GPT aka CONFIG_EFI_PARTITION)
> stores a GUID in the disk label to define the whole disk, plus another
> per-partition GUID and per-partition label.  So even if the file
> system doesn't have one, if you're using GPT, one *could* use those.
> I haven't hacked up mount to search for those though.  If there's
> enough interest, I'll do so.  Recall GPT is currently only used on
> ia64, though the code works fine on other arches including x86, and
> it's been decided (on l-k at least) that GPT will be the default disk
> label format for systems running 2.6.x kernels with disks >2TB, as the
> msdos label can't hold it.
> 
> > The boot disk, OTOH, is tough. Right now, we just assume the
> > sysadmin knows what's he's doing, when he installs lilo or grub on a
> > disk.  You care about the boot disk when installing lilo... maybe
> > there are similar situations too which I do not recall.  As Alan
> > said, besides EDD (only on newer boxes) there's really nothing.
> 
> EDD BIOSs are coming, slowly...  2 work today correctly, several more
> are "close but no cigar", it's all the rest that worry me.
> 
> There's one more trick that's being used successfully, which I would
> like to add to the EDD code.  That's "let BIOS help you out before
> installing".  i.e. you boot into a FreeDOS environment, write a
> system-unique disk signature to the boot disk (int13 device 80h)
> "BOOT" or something - we've got 4 bytes available in the msdos label
> for it, then reboot and let Linux go grab the signature,
> store it, and like edd.o does, export it to userspace.  Now from
> userspace one can see what Linux-named-disk has the signature you're
> looking for, and voila, you now solved it w/o needing EDD BIOSs.  But
> it requires a non-Linux boot step somewhere in the install process.
> 
> Thanks,
> Matt
> 
> -- 
> Matt Domsch
> Sr. Software Engineer, Lead Engineer
> Dell Linux Solutions www.dell.com/linux
> Linux on Dell mailing lists @ http://lists.us.dell.com
> -
> 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/
> 

DMA for ide-scsi?

[Mikael Pettersson]

On Sat, 13 Sep 2003 08:29:18 +0200, Jens Axboe <axboe@suse.de> wrote:
>> Actually with 2.6, you no longer need ide-scsi.  You'll need to upgrade 
>> your cdrecord tools and probably your burning GUI, if you use one.  I've 
>> been burning that way for several months now.  (I'm using xcdroast, 
>> though I need to start it with "-n" since I'm using cdrecord 2.01a18.)  
>> This actually works better for me than ide-scsi as for some reason it 
>> uses less CPU.
>
>That's because it _is_ faster. It contains no silly memory allocations
>for the buffer and data copying in the kernel, the data is mapped from
>the user buffer and DMA'ed directly from there. It also uses DMA where
>ide-scsi wont.

That begs the question: why won't ide-scsi do DMA?
I understand you'd rather see it disappear (:->) but since I use
it for other ATAPI devices as well, I'd like to see it maintained
and fully operational. Having DMA in ide-scsi would be nice.

(And the concept of using a SCSI API to ATA devices is in itself
not broken, even if the implementation has some problems.)

/Mikael

Re: DMA for ide-scsi?

[Alan Cox]

On Sad, 2003-09-13 at 12:01, Mikael Pettersson wrote:
> That begs the question: why won't ide-scsi do DMA?

Because nobody added it. Its that simple

> I understand you'd rather see it disappear (:->) but since I use
> it for other ATAPI devices as well, I'd like to see it maintained
> and fully operational. Having DMA in ide-scsi would be nice.

I don't see it vanishing either - people abuse IDE (especially SATA) for
weird stuff like high end scanners which want to use ide-scsi for sg. I
agree with Bart about ide-scsi for disks. For tape ide-tape isnt good
enough for newer stuff but that could be fixed either way

> (And the concept of using a SCSI API to ATA devices is in itself
> not broken, even if the implementation has some problems.)

ATA drives don't generally talk ATAPI as well so you have protocol
stuff. For Serial ATA that is what the current SATA code everyone is
using does and each SATA vendor has followed the same path because our
existing PATA code 

In 2.7 the SCSI layer split can get finished so it seperates "scsi the
protocol" from "queueing engine and handling for an intelligent
controller".

Right now its not too bad - error handling is entirely pluggable for
example.

2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

On Sat, Sep 13, 2003 at 07:04:36PM +0100, Alan Cox wrote:
> In 2.7 the SCSI layer split can get finished so it seperates "scsi the
> protocol" from "queueing engine and handling for an intelligent
> controller".

Yep, this is exactly my plan.  And exactly why libata must use
the SCSI layer in 2.4 and 2.6, and in 2.7 use the "queueing engine ..."
stuff that you describe.

There are a lot of pieces in the SCSI layer that I want to move "up" to
the block layer in 2.7:  ->queuecommand "queue one" callback and loop
(Jens has code for this already), error handling thread helper code,
low-level device driver registration structure[1], personality code
(disk, cdrom, tape, ....), support for host controllers which may have
host _or_ device (or both!) TCQ limits, and on and on.

That's a ton of code, and IMO it's not feasible to (a) recreate it
for 2.6 libata, or (b) do the "move up" in 2.6.0-testX and change ide,
scsi, block, ... drivers to use the new helpers and new structure.
Changes are too big this late in the 2.6 game.

As of next week (I'm presenting this at Intel Developer Forum), libata
will support "AHCI", Intel's next generation SATA controller.  Each PCI
device supports up to 32 SATA ports (one SATA device each).  Each port
supports up to 32 outstanding ATA commands (i.e. 32 tags), including a
64-bit-DMA-capable scatter-gather table.  The S/G doesn't have the silly
64K segment boundary worries, either.

Promise hardware is similar -- up to 10 "packets" (taskfiles) can be
queued per host... not per device.  SCSI layer handles this with just a
few knob-turns.

For 2.6, libata (unfortunately) requires the SCSI layer for ATA
devices, and libata drives real hardware that noone else can drive.

For 2.7, when all this code "moves up" -- basically adding a bunch of
helper functions to the block layer -- libata won't need to treat ATA
devices as SCSI devices.

Some developers have rightfully pointed out that disks going from
/dev/hdX to /dev/sdX might create some user confusion.  This hasn't been
the case in practice.  Partly because LABEL= is fairly prevalent, and
partly because libata is used for "only SATA" scenarios, which is by
definition new hardware.


On to /dev/disk...
Another interesting part of this "moving up" is that I want to unify the
personality code.  The various tape, cdrom, and disk modules for ide,
scsi, and others are quite similar.  And if you look closer at today's
block layer, you see that already everything is designed around "struct
request".  So I envision a more top-down structure, with helper
functions and callbacks combining to form:  /dev/disk, /dev/cdrom,
/dev/tape, ...

The generic "disk" personality code would take care of allocating block
device major/minors (i.e. register_blkdev duties), and generating
requests.  Existing ->prep_rq helpers will fill in the specific details.
Subsystem-specfic ioctls can be delivered as REQ_SPECIAL.

cdrom, tape, and friends follow a similar pattern.

"What about /dev/hda!"  Answer:  a simple remapping block device, which
simulates /dev/hdXX or /dev/sdXX, by remapping all requests to
/dev/diskXX.

So the next time you hear me say "libata must wait for 2.7 to ditch SCSI"
this is what I mean ;-)  These aren't unachieveable goals, either.  It's
mostly code shuffling.  This code mostly already exists today.

	Jeff


[1] low-level driver registers a set of callbacks, which are
either implemented in the driver itself (cciss, cpqarray) or mostly
library-based helper functions (ATA or SCSI).

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
and SCSI cdbs to a device.  (for the uninitiated, this is lower level
than block devices / cdrom devices / etc.)

 ... AF_BLOCK is not out of the question ;-)

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

On Sat, Sep 13, 2003 at 03:01:31PM -0400, Jeff Garzik wrote:
> Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles

lol.  That would be "out-of-band".

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jens Axboe]

On Sat, Sep 13 2003, Jeff Garzik wrote:
> Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
> and SCSI cdbs to a device.  (for the uninitiated, this is lower level
> than block devices / cdrom devices / etc.)
> 
>  ... AF_BLOCK is not out of the question ;-)

Eh... I wont comment on that. I think we are way into Garzik lala land
there :)

I'd prefer just keeping sg_io_hdr, but dumping sg. A fully fledged bsg
(block sg) implementation. That way programs continue to work like
before on ATAPI/SCSI, for ATA we can use it as a task file transport.

-- 
Jens Axboe

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

On Mon, Sep 15, 2003 at 09:34:45AM +0200, Jens Axboe wrote:
> On Sat, Sep 13 2003, Jeff Garzik wrote:
> > Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
> > and SCSI cdbs to a device.  (for the uninitiated, this is lower level
> > than block devices / cdrom devices / etc.)
> > 
> >  ... AF_BLOCK is not out of the question ;-)
> 
> Eh... I wont comment on that. I think we are way into Garzik lala land
> there :)
> 
> I'd prefer just keeping sg_io_hdr, but dumping sg. A fully fledged bsg
> (block sg) implementation. That way programs continue to work like
> before on ATAPI/SCSI, for ATA we can use it as a task file transport.

I don't propose dumping the ugly "submit cdb/taskfile" ioctls, but we do
need to deprecate them.  The ioctls are awful for throughput, async
queueing, and the like.  And of course in general, ioctls are evil :)

And we should deprecate them with a solution that aligns what with Linus
described in Dec 2001 on lkml:  a chrdev where userland write(2)s cdbs
and taskfiles, and read(2)s the results.  This is where my thinking
picked up:  if we are creating a chrdev to send "packets" and receive
responses to those packets............  <insert conclusion here>

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jens Axboe]

On Tue, Sep 16 2003, Jeff Garzik wrote:
> On Mon, Sep 15, 2003 at 09:34:45AM +0200, Jens Axboe wrote:
> > On Sat, Sep 13 2003, Jeff Garzik wrote:
> > > Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
> > > and SCSI cdbs to a device.  (for the uninitiated, this is lower level
> > > than block devices / cdrom devices / etc.)
> > > 
> > >  ... AF_BLOCK is not out of the question ;-)
> > 
> > Eh... I wont comment on that. I think we are way into Garzik lala land
> > there :)
> > 
> > I'd prefer just keeping sg_io_hdr, but dumping sg. A fully fledged bsg
> > (block sg) implementation. That way programs continue to work like
> > before on ATAPI/SCSI, for ATA we can use it as a task file transport.
> 
> I don't propose dumping the ugly "submit cdb/taskfile" ioctls, but we do
> need to deprecate them.  The ioctls are awful for throughput, async
> queueing, and the like.  And of course in general, ioctls are evil :)
> 
> And we should deprecate them with a solution that aligns what with Linus
> described in Dec 2001 on lkml:  a chrdev where userland write(2)s cdbs
> and taskfiles, and read(2)s the results.  This is where my thinking
> picked up:  if we are creating a chrdev to send "packets" and receive
> responses to those packets............  <insert conclusion here>

== bsg, block sg. Did you read what I wrote? :). I started implementing
this and have something that barely works. You just bind a block device
to a /dev/sg* char device and use read/write on that. Aka sg.

I don't want ioctls command submission interfaces more than you do.

-- 
Jens Axboe

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

Jens Axboe wrote:
> On Tue, Sep 16 2003, Jeff Garzik wrote:

>>And we should deprecate them with a solution that aligns what with Linus
>>described in Dec 2001 on lkml:  a chrdev where userland write(2)s cdbs
>>and taskfiles, and read(2)s the results.  This is where my thinking
>>picked up:  if we are creating a chrdev to send "packets" and receive
>>responses to those packets............  <insert conclusion here>
> 
> 
> == bsg, block sg. Did you read what I wrote? :). I started implementing
> this and have something that barely works. You just bind a block device
> to a /dev/sg* char device and use read/write on that. Aka sg.

sg needs some modifications -- for example it errors out instead of 
sleeps on queue full -- but sounds good to me.


> I don't want ioctls command submission interfaces more than you do.

Groovy.

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Alan Cox]

On Sad, 2003-09-20 at 19:28, Jeff Garzik wrote:
> sg needs some modifications -- for example it errors out instead of 
> sleeps on queue full -- but sounds good to me.

Is that an error and change in behaviour ?

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

Alan Cox wrote:
> On Sad, 2003-09-20 at 19:28, Jeff Garzik wrote:
> 
>>sg needs some modifications -- for example it errors out instead of 
>>sleeps on queue full -- but sounds good to me.
> 
> 
> Is that an error and change in behaviour ?


No and yes.  :)

Current sg breaks the Unix model of write(2)... you shouldn't error out 
if the queue will "probably" become available again.

	Jeff

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Alan Cox]

On Sad, 2003-09-20 at 23:22, Jeff Garzik wrote:
> > Is that an error and change in behaviour ?
> 
> 
> No and yes.  :)
> 
> Current sg breaks the Unix model of write(2)... you shouldn't error out 
> if the queue will "probably" become available again.

Thats what I thought - because apps want to know if the queue is full
when doing raw scsi work some of the time. Would the change break any
known apps - if not it seems fine (providing O_NDELAY is supported)

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jens Axboe]

On Sat, Sep 20 2003, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Tue, Sep 16 2003, Jeff Garzik wrote:
> 
> >>And we should deprecate them with a solution that aligns what with Linus
> >>described in Dec 2001 on lkml:  a chrdev where userland write(2)s cdbs
> >>and taskfiles, and read(2)s the results.  This is where my thinking
> >>picked up:  if we are creating a chrdev to send "packets" and receive
> >>responses to those packets............  <insert conclusion here>
> >
> >
> >== bsg, block sg. Did you read what I wrote? :). I started implementing
> >this and have something that barely works. You just bind a block device
> >to a /dev/sg* char device and use read/write on that. Aka sg.
> 
> sg needs some modifications -- for example it errors out instead of 
> sleeps on queue full -- but sounds good to me.

Definitely. bsg will be a new implementation from scratch, also dumping
a lot of really (imo) useless "features" that clutter up the code. And
yes, of course it should honor the typical write(2) model :)

-- 
Jens Axboe

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Bartlomiej Zolnierkiewicz]

On Saturday 13 of September 2003 20:49, Jeff Garzik wrote:
> On Sat, Sep 13, 2003 at 07:04:36PM +0100, Alan Cox wrote:
> > In 2.7 the SCSI layer split can get finished so it seperates "scsi the
> > protocol" from "queueing engine and handling for an intelligent
> > controller".
>
> Yep, this is exactly my plan.  And exactly why libata must use
> the SCSI layer in 2.4 and 2.6, and in 2.7 use the "queueing engine ..."
> stuff that you describe.
>
> There are a lot of pieces in the SCSI layer that I want to move "up" to
> the block layer in 2.7:  ->queuecommand "queue one" callback and loop
> (Jens has code for this already), error handling thread helper code,
> low-level device driver registration structure[1], personality code
> (disk, cdrom, tape, ....), support for host controllers which may have
> host _or_ device (or both!) TCQ limits, and on and on.
>
> That's a ton of code, and IMO it's not feasible to (a) recreate it
> for 2.6 libata, or (b) do the "move up" in 2.6.0-testX and change ide,
> scsi, block, ... drivers to use the new helpers and new structure.
> Changes are too big this late in the 2.6 game.
>
> As of next week (I'm presenting this at Intel Developer Forum), libata
> will support "AHCI", Intel's next generation SATA controller.  Each PCI
> device supports up to 32 SATA ports (one SATA device each).  Each port
> supports up to 32 outstanding ATA commands (i.e. 32 tags), including a
> 64-bit-DMA-capable scatter-gather table.  The S/G doesn't have the silly
> 64K segment boundary worries, either.
>
> Promise hardware is similar -- up to 10 "packets" (taskfiles) can be
> queued per host... not per device.  SCSI layer handles this with just a
> few knob-turns.
>
> For 2.6, libata (unfortunately) requires the SCSI layer for ATA
> devices, and libata drives real hardware that noone else can drive.
>
> For 2.7, when all this code "moves up" -- basically adding a bunch of
> helper functions to the block layer -- libata won't need to treat ATA
> devices as SCSI devices.

s/ATA/SATA/

ATA and SATA will still need their own driver(s) aware of driver-model,
sysfs, ATA quirks/tuning etc.  I am working on this part currently, so you can
concentrate on new, sexy SATA, leaving all dirty, legacy ATA for me.

For all other stuff described in your mail I can only say: HELL YEAH!.

> Some developers have rightfully pointed out that disks going from
> /dev/hdX to /dev/sdX might create some user confusion.  This hasn't been
> the case in practice.  Partly because LABEL= is fairly prevalent, and
> partly because libata is used for "only SATA" scenarios, which is by
> definition new hardware.
>
>
> On to /dev/disk...
> Another interesting part of this "moving up" is that I want to unify the
> personality code.  The various tape, cdrom, and disk modules for ide,
> scsi, and others are quite similar.  And if you look closer at today's
> block layer, you see that already everything is designed around "struct
> request".  So I envision a more top-down structure, with helper
> functions and callbacks combining to form:  /dev/disk, /dev/cdrom,
> /dev/tape, ...
>
> The generic "disk" personality code would take care of allocating block
> device major/minors (i.e. register_blkdev duties), and generating
> requests.  Existing ->prep_rq helpers will fill in the specific details.
> Subsystem-specfic ioctls can be delivered as REQ_SPECIAL.
>
> cdrom, tape, and friends follow a similar pattern.
>
> "What about /dev/hda!"  Answer:  a simple remapping block device, which
> simulates /dev/hdXX or /dev/sdXX, by remapping all requests to
> /dev/diskXX.
>
> So the next time you hear me say "libata must wait for 2.7 to ditch SCSI"
> this is what I mean ;-)  These aren't unachieveable goals, either.  It's
> mostly code shuffling.  This code mostly already exists today.
>
> 	Jeff
>
>
> [1] low-level driver registers a set of callbacks, which are
> either implemented in the driver itself (cciss, cpqarray) or mostly
> library-based helper functions (ATA or SCSI).

Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)

[Jeff Garzik]

On Sat, Sep 13, 2003 at 09:24:05PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Saturday 13 of September 2003 20:49, Jeff Garzik wrote:
> > For 2.6, libata (unfortunately) requires the SCSI layer for ATA
> > devices, and libata drives real hardware that noone else can drive.
> >
> > For 2.7, when all this code "moves up" -- basically adding a bunch of
> > helper functions to the block layer -- libata won't need to treat ATA
> > devices as SCSI devices.
> 
> s/ATA/SATA/
> 
> ATA and SATA will still need their own driver(s) aware of driver-model,
> sysfs, ATA quirks/tuning etc.

Agreed.  Though I think some of your work in sysfs area can be made
common.


> I am working on this part currently, so you can
> concentrate on new, sexy SATA, leaving all dirty, legacy ATA for me.

Sounds good to me ;-)  Though I'll definitely want to work together with
you on several issues in 2.7...


> For all other stuff described in your mail I can only say: HELL YEAH!.

;-)

	Jeff