Re: IDE? IDE-TNG driver

Re: IDE? IDE-TNG driver

[David Balazic]

Andre Hedrick (andre@linux-ide.org) wrote :
> I will hand it to you guys on a silver platter IDE-TNG. 
> 
> Below yields modular chipsets and channel index registration. 
> Selectable IOPS for arch independent Taskfile Transport layers. 
> Now to finish the job with device class link lists to address fully 
> modular subdrivers. It also includes 1st generation of device open and 
> select calls of subdrivers. 

Will it support DISCONNECT/RECONNECT ( of course named differently
in ATA, "overlapped command feature" if I'm not mistaken ) ?

If not, consider this as a request for implementation :-)
I can offer (beta)testing ( I have two ATAPI CD-ROMs ( one is a
rewriter ) and a HD , that all claim ( according to hdparm -I output )
to support overlapped commands ) and maybe money, if everything else
fails :-)

I expect this to improve performance ( latency actually ) on the ATA
channel when slow devices are involved ( and even fast devices can have
slow moments, like a read of a slightly broken sector ).

Best regards,
david balazic

 
> You have ide-cd registered on a cdrw and you want to burn a cd? 
> open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX) 
> open(/dev/sg) and burn baby burn. 
> close(/dev/sg) releases transform_subdriver_scsi 
> open(/dev/hdX) load native atapi transport. 
> 
> Will do it for TAPE-FLOPPY-DVDCD/RW ... 
> 
> Uniform Multi-Platform E-IDE driver Revision: 6.31 
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx 
> SiI680: IDE controller on PCI bus 00 dev 90 
> SiI680: chipset revision 1 
> SiI680: not 100% native mode: will probe irqs later 
> SiI680: BASE CLOCK == 133 
>     ide0: MMIO-DMA at 0xe080df00-0xe080df07, BIOS settings: hda:pio, hdb:pio 
>     ide1: MMIO-DMA at 0xe080df08-0xe080df0f, BIOS settings: hdc:pio, hdd:pio 
> hda: Maxtor 4G160J8, ATA DISK drive 
> hdb: Maxtor 4G160J8, ATA DISK drive 
> ide0 at 0xe080df80-0xe080df87,0xe080df8a on irq 9 
> hda: host protected area => 1 
> hda: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133) 
> hdb: host protected area => 1 
> hdb: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133) 
> hdc: Maxtor 4G160J8, ATA DISK drive 
> hdd: Maxtor 4G160J8, ATA DISK drive 
> ide1 at 0xe080dfc0-0xe080dfc7,0xe080dfca on irq 9 
> hdc: host protected area => 1 
> hdc: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133) 
> hdd: host protected area => 1 
> hdd: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133) 
> PIIX3: IDE controller on PCI bus 00 dev 39 
> PIIX3: chipset revision 0 
> PIIX3: not 100% native mode: will probe irqs later 
>     ide2: BM-DMA at 0xffa0-0xffa7, BIOS settings: hde:DMA, hdf:DMA 
>     ide3: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdg:pio, hdh:pio 
> hde: ATAPI 44X CDROM, ATAPI CD/DVD-ROM drive 
> hdf: CREATIVEDVD5240E-1, ATAPI CD/DVD-ROM drive 
> ide2 at 0x1f0-0x1f7,0x3f6 on irq 14 
> hde: ATAPI 40X CD-ROM drive, 128kB Cache, (U)DMA 
> Uniform CD-ROM driver Revision: 3.12 
> hdf: ATAPI 32X DVD-ROM drive, 512kB Cache, DMA 
> Partition check: 
>  /dev/ide/host0/bus0/target0/lun0: p1 
>  /dev/ide/host0/bus0/target1/lun0: p1 
>  /dev/ide/host0/bus1/target0/lun0: p1 
>  /dev/ide/host0/bus1/target1/lun0: p1 
> 
> If this is what you want, this is what I have to put on the table. 
> If you do not I will delete the code. 
> 
> Regards, 
> 
> Andre Hedrick 
> LAD Storage Consulting Group

Re: IDE?

[Matthias Andree]

On Fri, 16 Aug 2002, Linus Torvalds wrote:

> In article <2444170000.1029531611@flay>,
> Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
> >So did Linus get disk corruption or is something else afoot?
> 
> Martin gave up the fight he had to do all the time, so..

Not having seen much of all the work, this sounds like it is a sad day,
for Martin who contributed a lot of his time to work on the issues,
while people seemed not to be too grateful, screaming from either end of
the road, this must wear people out.

Is there a way how the improvements that parts of the stuff have
received can be rescued somehow? Or at least the knowledge of which can
be used somewhat directly for a IDE-TNG driver? I'd find it really sad
to just let go of so much time that had been invested into the project
-- but keep in mind I have NO knowledge of the gory details of the last
2.5 IDE stuff.

-- 
Matthias Andree

Re: IDE? IDE-TNG driver

[Andre Hedrick]

I will hand it to you guys on a silver platter IDE-TNG.

Below yields modular chipsets and channel index registration.
Selectable IOPS for arch independent Taskfile Transport layers.
Now to finish the job with device class link lists to address fully
modular subdrivers.  It also includes 1st generation of device open and
select calls of subdrivers.

You have ide-cd registered on a cdrw and you want to burn a cd?
open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX)
open(/dev/sg) and burn baby burn.
close(/dev/sg) releases transform_subdriver_scsi
open(/dev/hdX) load native atapi transport.

Will do it for TAPE-FLOPPY-DVDCD/RW ...


Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SiI680: IDE controller on PCI bus 00 dev 90
SiI680: chipset revision 1
SiI680: not 100% native mode: will probe irqs later
SiI680: BASE CLOCK == 133
    ide0: MMIO-DMA at 0xe080df00-0xe080df07, BIOS settings: hda:pio, hdb:pio
    ide1: MMIO-DMA at 0xe080df08-0xe080df0f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 4G160J8, ATA DISK drive
hdb: Maxtor 4G160J8, ATA DISK drive
ide0 at 0xe080df80-0xe080df87,0xe080df8a on irq 9
hda: host protected area => 1
hda: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
hdb: host protected area => 1
hdb: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
hdc: Maxtor 4G160J8, ATA DISK drive
hdd: Maxtor 4G160J8, ATA DISK drive
ide1 at 0xe080dfc0-0xe080dfc7,0xe080dfca on irq 9
hdc: host protected area => 1
hdc: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
hdd: host protected area => 1
hdd: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=19929/255/63, UDMA(133)
PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xffa0-0xffa7, BIOS settings: hde:DMA, hdf:DMA
    ide3: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdg:pio, hdh:pio
hde: ATAPI 44X CDROM, ATAPI CD/DVD-ROM drive
hdf: CREATIVEDVD5240E-1, ATAPI CD/DVD-ROM drive
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
hde: ATAPI 40X CD-ROM drive, 128kB Cache, (U)DMA
Uniform CD-ROM driver Revision: 3.12
hdf: ATAPI 32X DVD-ROM drive, 512kB Cache, DMA
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1
 /dev/ide/host0/bus0/target1/lun0: p1
 /dev/ide/host0/bus1/target0/lun0: p1
 /dev/ide/host0/bus1/target1/lun0: p1


If this is what you want, this is what I have to put on the table.
If you do not I will delete the code.


Regards,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 17 Aug 2002, Matthias Andree wrote:

> On Fri, 16 Aug 2002, Linus Torvalds wrote:
> 
> > In article <2444170000.1029531611@flay>,
> > Martin J. Bligh <Martin.Bligh@us.ibm.com> wrote:
> > >So did Linus get disk corruption or is something else afoot?
> > 
> > Martin gave up the fight he had to do all the time, so..
> 
> Not having seen much of all the work, this sounds like it is a sad day,
> for Martin who contributed a lot of his time to work on the issues,
> while people seemed not to be too grateful, screaming from either end of
> the road, this must wear people out.
> 
> Is there a way how the improvements that parts of the stuff have
> received can be rescued somehow? Or at least the knowledge of which can
> be used somewhat directly for a IDE-TNG driver? I'd find it really sad
> to just let go of so much time that had been invested into the project
> -- but keep in mind I have NO knowledge of the gory details of the last
> 2.5 IDE stuff.
> 
> -- 
> Matthias Andree
> -
> 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: IDE? IDE-TNG driver

[Skip Ford]

Andre Hedrick wrote:
> 
> I will hand it to you guys on a silver platter IDE-TNG.
>
[snip]
> 
> If this is what you want, this is what I have to put on the table.
> If you do not I will delete the code.

Can't you just create a patch and send it to the list?  I for one would
like to try out your code.  Just diff it and send it without the song
and dance please.

-- 
Skip

Re: IDE? IDE-TNG driver

[Matthew D. Pitts]

I agree. Send a patch and I will test it, too.

----- Original Message -----
From: "Skip Ford" <skip.ford@verizon.net>
To: "Andre Hedrick" <andre@linux-ide.org>
Cc: <linux-kernel@vger.kernel.org>
Sent: Saturday, August 17, 2002 9:56 AM
Subject: Re: IDE? IDE-TNG driver


> Andre Hedrick wrote:
> >
> > I will hand it to you guys on a silver platter IDE-TNG.
> >
> [snip]
> >
> > If this is what you want, this is what I have to put on the table.
> > If you do not I will delete the code.
>
> Can't you just create a patch and send it to the list?  I for one would
> like to try out your code.  Just diff it and send it without the song
> and dance please.
>
> --
> Skip
> -
> 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: IDE? IDE-TNG driver

[Alan Cox]

You can do the switch (one way only right now) in 2.4.20-pre2-ac3.
Ultimately for 2.4 I want to get to the point where open() tries to
switch between srfoo and hdfoo and locks out the other user. For 2.5 we
can get more esoteric. 2.4 has to continue to just work

Re: IDE? IDE-TNG driver

[Ruth Ivimey-Cook]

On Sat, 17 Aug 2002, Andre Hedrick wrote:

>
>I will hand it to you guys on a silver platter IDE-TNG.
>
>Below yields modular chipsets and channel index registration.
>Selectable IOPS for arch independent Taskfile Transport layers.
...
>You have ide-cd registered on a cdrw and you want to burn a cd?
>open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX)
>open(/dev/sg) and burn baby burn.
>close(/dev/sg) releases transform_subdriver_scsi
>open(/dev/hdX) load native atapi transport.


Andre, I see the thought, but surely this is prine to races and other 
difficulties.

Wouldn't it be better to provide an IDE ioctl() that enables the caller to use 
set the SCSI transport on an open FD, so your sequence becomes:

 open(/dev/hdX)
 ioctl(transform_subdriver_scsi)
 ioctl(scsi_ops)
 write(data)
 close(/dev/hdX)

Ruth

-- 
Ruth Ivimey-Cook
Software engineer and technical writer.

Re: IDE? IDE-TNG driver

[Andre Hedrick]

ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)

Where bool does the subdriver switch.
Just that ioctl's are being blasted and people using are frowned upon.

This was a feature Alan Cox poked me for to try and move away from how
modules are basically an all or nothing grab-all.

Regards,

Andre Hedrick
LAD Storage Consulting Group

On Sat, 17 Aug 2002, Ruth Ivimey-Cook wrote:

> On Sat, 17 Aug 2002, Andre Hedrick wrote:
> 
> >
> >I will hand it to you guys on a silver platter IDE-TNG.
> >
> >Below yields modular chipsets and channel index registration.
> >Selectable IOPS for arch independent Taskfile Transport layers.
> ...
> >You have ide-cd registered on a cdrw and you want to burn a cd?
> >open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX)
> >open(/dev/sg) and burn baby burn.
> >close(/dev/sg) releases transform_subdriver_scsi
> >open(/dev/hdX) load native atapi transport.
> 
> 
> Andre, I see the thought, but surely this is prine to races and other 
> difficulties.
> 
> Wouldn't it be better to provide an IDE ioctl() that enables the caller to use 
> set the SCSI transport on an open FD, so your sequence becomes:
> 
>  open(/dev/hdX)
>  ioctl(transform_subdriver_scsi)
>  ioctl(scsi_ops)
>  write(data)
>  close(/dev/hdX)
> 
> Ruth
> 
> -- 
> Ruth Ivimey-Cook
> Software engineer and technical writer.
> 
> -
> 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: IDE? IDE-TNG driver

[Ruth Ivimey-Cook]

On Sat, 17 Aug 2002, Andre Hedrick wrote:
>
>ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)

Seems fine to me...

>Where bool does the subdriver switch.
>Just that ioctl's are being blasted and people using are frowned upon.

? so how is cdrecord (or whatever) supposed to do its stuff -- is it ioctl()  
-> fcntl()? If so, I suppose that's ok, but the basic premise still exists,
surely?

>This was a feature Alan Cox poked me for to try and move away from how
>modules are basically an all or nothing grab-all.

I don't think modules are the answer to any of this:
 a) some people want basically module-less kernels
 b) in some environments, you need to be able to select the IO mechanism 
    without the ability to select the module to load.

anyway...

<slightly confused by it all>


Ruth

-- 
Ruth Ivimey-Cook
Software engineer and technical writer.

Re: IDE? IDE-TNG driver

[Andre Hedrick]

On Sat, 17 Aug 2002, Ruth Ivimey-Cook wrote:

> On Sat, 17 Aug 2002, Andre Hedrick wrote:
> >
> >ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)
> 
> Seems fine to me...
> 
> >Where bool does the subdriver switch.
> >Just that ioctl's are being blasted and people using are frowned upon.
> 
> ? so how is cdrecord (or whatever) supposed to do its stuff -- is it ioctl()  
> -> fcntl()? If so, I suppose that's ok, but the basic premise still exists,
> surely?
> 
> >This was a feature Alan Cox poked me for to try and move away from how
> >modules are basically an all or nothing grab-all.
> 
> I don't think modules are the answer to any of this:
>  a) some people want basically module-less kernels

This is designed to work regardless.

/dev/hdc == ide-cd builtin
insmod ide-scsi

ide_ioctl(fd, HDIO_SET_IDE_SCSI, bool)

converts /dev/hdc == ide-cd builtin to ide-scsi(add-in-module).

>  b) in some environments, you need to be able to select the IO mechanism 
>     without the ability to select the module to load.

See above, I think it solves the problem.
Once ide-scsi is added to the ide_module link list it is as good as
built-in.

> anyway...
> 
> <slightly confused by it all>

Me too, because I do not know the direction goal so I am doing the very
best I can.  What I really need is an active development team.

Before me:

Mark Lord, Gadi Oxman, Eric Anderson worked well.

ML ide-disk and ide.c global.
GO ide-floppy, ide-tape, ide-scsi
EA ide-cd

Anyways that was long before transport layer w/ all the hardware issues
began to dominate things.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: IDE? IDE-TNG driver

[Erik Andersen]

On Sat Aug 17, 2002 at 04:06:46PM -0700, Andre Hedrick wrote:
> Mark Lord, Gadi Oxman, Eric Anderson worked well.

All these years later, I'm still known to submit 
the occasional patch....

 -Erik

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

Re: IDE? IDE-TNG driver

[Scott Bronson]

On Sat, 2002-08-17 at 15:57, Ruth Ivimey-Cook wrote:
>  a) some people want basically module-less kernels

Everyone I've heard advocating a moduleless kernel uses an argument that
boils down to "it's slightly more secure."  Does anybody have a GOOD
reason for not using modules?  Obsolete or embedded hardware arguments
don't count.


>  b) in some environments, you need to be able to select the IO mechanism 
>     without the ability to select the module to load.

If that's the case, won't a kernel parameter suffice?  Can you
elaborate?

    - Scott

Re: IDE? IDE-TNG driver

[Scott Bronson]

> Everyone I've heard advocating a moduleless kernel uses an argument that
> boils down to "it's slightly more secure."  Does anybody have a GOOD
> reason for not using modules?  Obsolete or embedded hardware arguments
> don't count.

Someone replied off-list saying that initrds are too hard to create.

That's true.  They are.  One day, hopefully that will change.

Any other reasons?

    - Scott

Re: IDE? IDE-TNG driver

[Thomas Molina]

On 17 Aug 2002, Scott Bronson wrote:

> > Everyone I've heard advocating a moduleless kernel uses an argument that
> > boils down to "it's slightly more secure."  Does anybody have a GOOD
> > reason for not using modules?  Obsolete or embedded hardware arguments
> > don't count.
> 
> Someone replied off-list saying that initrds are too hard to create.
> 
> That's true.  They are.  One day, hopefully that will change.
> 
> Any other reasons?

Wouldn't the logic be a lot simpler if kernel developers didn't have to 
worry about whether their module was built in or inserted at some point in 
the future?  All the bits could be assembled and symbols would be resolved 
at compile time.

ICBW but it appears the largest percentage of users have modules inserted 
at boot time, never to be ejected or disturbed.  The modules might as well 
be built in.

I've never really grokked the whole initrd anyway.  What is the point of 
building a kernel minus the bits it needs to actually boot the system?  
That just forces this ludicrous jerry-rigged mess to provide the 
capabilities that should have been built in at compile time.

Of course, we're never going to get away from modules now anyway, so the 
argument is probably moot.  With PCCARD, USB, Firewire, and Hotplug PCI 
there are too many ways to add components not present when the system is 
built on an adhoc basis.  The alternative would be a bloated monstrosity 
with dead code not needed by most people.  I remember my early days of 
Linux and seeing literally dozens of kernels compiled with different 
options, with no clue how to choose the right one for my system.

Re: IDE? IDE-TNG driver

[CaT]

On Sat, Aug 17, 2002 at 08:47:30PM -0700, Scott Bronson wrote:
> > Everyone I've heard advocating a moduleless kernel uses an argument that
> > boils down to "it's slightly more secure."  Does anybody have a GOOD
> > reason for not using modules?  Obsolete or embedded hardware arguments
> > don't count.
> 
> Someone replied off-list saying that initrds are too hard to create.
> 
> That's true.  They are.  One day, hopefully that will change.
> 
> Any other reasons?

Because I shouldn't have to use a feature if I don't need to use a
feature?

I dunno... I've not once heard a decent argument as to why I should
modulerise the ide subsystem, or ext3 or the video drivers and so on.

Where I -do- need to use it though, I do happily use it. One case is to
reset the eepro100 driver so that it works after my computer is brought
out of suspend mode (either RAM or disk).

But why should I -not- make a monolithic kernel when I don't have any
reason to do so? If you can provide me with some decent ones, I'll
happily start...

-- 
   "There was a moo from under the blanket, and I knew it was not a person,
   but a calf."
         - http://www.iol.co.za/index.php?art_id=qw1028795041273B265

Re: IDE? IDE-TNG driver

[David Lang]

A couple things in favor of a monlithic kernel.

there is a slight performance advantage becouse the calls don't
have to be far calls

there is a slight memory advantage becouse you don't have the fraction of
a page of ram lost per module

with a monolithic kernel there's no chance of making a mistake and trying
to use incompatable modules with your kernel (and before you say that this
can be fixed with the kernel build remember that for many people the build
machine is not where the kernel will be run)

David Lang


On 17 Aug 2002, Scott
Bronson wrote:

> Date: 17 Aug 2002 17:28:38 -0700
> From: Scott Bronson <bronson@rinspin.com>
> To: Ruth Ivimey-Cook <Ruth.Ivimey-Cook@ivimey.org>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: IDE?  IDE-TNG driver
>
> On Sat, 2002-08-17 at 15:57, Ruth Ivimey-Cook wrote:
> >  a) some people want basically module-less kernels
>
> Everyone I've heard advocating a moduleless kernel uses an argument that
> boils down to "it's slightly more secure."  Does anybody have a GOOD
> reason for not using modules?  Obsolete or embedded hardware arguments
> don't count.
>
>
> >  b) in some environments, you need to be able to select the IO mechanism
> >     without the ability to select the module to load.
>
> If that's the case, won't a kernel parameter suffice?  Can you
> elaborate?
>
>     - Scott
>
>
>
> -
> 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: IDE? IDE-TNG driver

[Helge Hafting]

Scott Bronson wrote:
> 
> On Sat, 2002-08-17 at 15:57, Ruth Ivimey-Cook wrote:
> >  a) some people want basically module-less kernels
> 
> Everyone I've heard advocating a moduleless kernel uses an argument that
> boils down to "it's slightly more secure."  Does anybody have a GOOD
> reason for not using modules?  

1. "No need".  Doesn't apply to everybody of course, but
   many have enough memory and don't plug in much new stuff.
   Recompiling & booting for the rare occation where you
   bought a new usb device is ok.  

2. A simpler setup.  No /etc/modules.conf to worry about.
   Compiling ALSA into the kernel surely made life easier.
   even more so when also using devfs...

3. Performance.  Compiled-in stuff is always there, and
   on x86 it exists in the kernel's 4M page so no
   TLB loading overhead either.

> Someone replied off-list saying that initrds are too hard to create.
Actually, that isn't an argument for linking everything in.
All you need is the drivers for your root fs and root device.
The rest may still be modular, loaded from /lib/modules on
that root fs.


Helge Hafting