IDE?

So did Linus get disk corruption or is something else afoot?

9 hours  axboe  1.456.34.40  Delete 2.5 IDE core
9 hours  axboe  1.456.34.41  Add 2.4 IDE core, based on late 2.4.19-pre-acX version  

In article <2444170000.1029531611@flay>,

Martin gave up the fight he had to do all the time, so..

Linus

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

There were a few bits I submitted that should probably go in - I'll look at reviving them when I'm less busy and the direction of IDE stuff has settled down a bit.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

[snip]

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

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

----- Original Message -----
From: "Skip Ford" <[email protected]>
To: "Andre Hedrick" <[email protected]>
Cc: <[email protected]>
Sent: Saturday, August 17, 2002 9:56 AM
Subject: Re: IDE? IDE-TNG driver

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

...

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.

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

Seems fine to me...

? 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?

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.

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).

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.

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

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--

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.

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

- Scott

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

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.

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

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

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.

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