libata update posted
Just some minor updates. The main one is that ATA software reset is now considered reliable, so it is now the default. Execute-Device-Diagnostic bus reset method remains in place and can be easily re-enabled with a flag.
libata has also moved (slightly) to a new home:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, and future patches will appear in the same location.
Look for more updates this weekend, including bug fixes from Dell and Red Hat, and better MMIO support. And maybe a special surprise. :)
Jeff
Quoted 11 lines · Jeff Garzik
Just some minor updates. The main one is that ATA software reset is now considered reliable, so it is now the default. Execute-Device-Diagnostic bus reset method remains in place and can be easily re-enabled with a flag.
libata has also moved (slightly) to a new home:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, and future patches will appear in the same location.
The patch for 2.4 kills drivers/char/defkeymap.c.
Is this in on purpose ? I think this is autogenerated but not killed in mrproper.
Signature · 4 lines
J.A. Magallon <[email protected]> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.23-pre4-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))
Quoted 5 lines · Jeff Garzik
Just some minor updates. The main one is that ATA software reset is now considered reliable, so it is now the default. Execute-Device-Diagnostic bus reset method remains in place and can be easily re-enabled with a flag.
Quoted 9 lines
libata has also moved (slightly) to a new home:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, and future patches will appear in the same location.
Look for more updates this weekend, including bug fixes from Dell and Red Hat, and better MMIO support. And maybe a special surprise. :)
Any user documentation, like modules names and how to make it work ? I could write the Configure.help entries.
I suppose you load the PIIX/VIA modules and you have one other scsi bus.
Any pointer ?
Just adding it to -jam before publishing pre4-jam1.
Signature · 4 lines
J.A. Magallon <[email protected]> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.23-pre4-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))
Quoted 10 lines · J.A. Magallon
Quoted 8 lines · Jeff Garzik
Just some minor updates. The main one is that ATA software reset is now considered reliable, so it is now the default. Execute-Device-Diagnostic bus reset method remains in place and can be easily re-enabled with a flag.
libata has also moved (slightly) to a new home:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
Quoted 7 lines
Quoted 3 lines
The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, and future patches will appear in the same location.
The patch for 2.4 kills
drivers/char/defkeymap.c.
Is this in on purpose ? I think this is autogenerated but not killed in mrproper.
Yep, that's an autogenerated file. I nudge Marcelo to "bk rm" it every now and then :) Just remove it from the patch and you'll be ok.
I have to "rm -f drivers/char/defkeymap.c" on occasion, in order to do some bk stuff, too.
Jeff
Quoted 13 lines · J.A. Magallon
Quoted 11 lines · Jeff Garzik
Just some minor updates. The main one is that ATA software reset is now considered reliable, so it is now the default. Execute-Device-Diagnostic bus reset method remains in place and can be easily re-enabled with a flag.
libata has also moved (slightly) to a new home:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, and future patches will appear in the same location.
Quoted 8 lines
Quoted 3 lines
Look for more updates this weekend, including bug fixes from Dell and Red Hat, and better MMIO support. And maybe a special surprise. :)
Any user documentation, like modules names and how to make it work ? I could write the Configure.help entries.
I suppose you load the PIIX/VIA modules and you have one other scsi bus.
The 2.5 patch should have Configure.help entries. Any assistance in writing documentation is greatly appreciated, though :) I hope to get much more than just a dry API reference in Documentation/Docbook/libata.tmpl, so any added information should probably be noted in there.
No user documentation, but feel free to ask me questions. Here's a quick overview:
ata_piix, ata_via -- low-level driver modules
libata -- shared code module for the above
modprobe ata_piix or ata_via, and it will make your SATA devices appear as a new SCSI bus. Each SATA port is represented by a separate SCSI bus.
Currently in 2.4 and 2.6, both ATA and ATAPI devices appear as SCSI devices. However in 2.7, ATA devices (i.e. hard drives) will not go through the SCSI layer. ATAPI devices will continue to use some of the SCSI layer code in 2.7.
Currently only Intel ICH5 SATA is well tested. VIA SATA was just added, and Intel PATA support exists, but it is recommended that you use drivers/ide for PATA support.
Current -ac and -pac kernels #if-0 the ICH5 SATA pci id from drivers/ide/pci/piix.c, preferring to let libata drive that. That's done not only to expose libata to testing, but also for pragmatic reasons: drivers/ide will hang on many ICH5 SATA hosts, when they are in "native mode"[1].
Jeff
[1] native mode is when a PCI IDE device is configured to obtain all its resources from the PCI io space, and use PCI interrupts. The other side of the coin is legacy mode, which uses legacy IDE ports 0x1f0/0x170 and legacy ISA irqs 14/15.
Quoted 11 lines · Jeff Garzik
Quoted 3 lines · J.A. Magallon
The patch for 2.4 kills
drivers/char/defkeymap.c.
Is this in on purpose ? I think this is autogenerated but not killed in mrproper.Yep, that's an autogenerated file. I nudge Marcelo to "bk rm" it every now and then :) Just remove it from the patch and you'll be ok.
I have to "rm -f
drivers/char/defkeymap.c" on occasion, in order to do some bk stuff, too.
Long ago it happened every once in a while that I added a key type. In such a case one got new kernel keyboard headers, had to recompile loadkeys with the new headers, use that new loadkeys to regenerate defkeymap.c, and then recompile the kernel.
This shows why defkeymap.c is not generated in the kernel build but distributed.
Andries
Quoted 2 lines · Andries Brouwer
This shows why
defkeymap.cis not generated in the kernel build but distributed.
There is a difference between distributed generating files, and checking generated files into a repository... I do not advocate changing the tarball, just the BK repo behind it.
Jeff
Quoted 6 lines · Jeff Garzik
Quoted 2 lines
This shows why
defkeymap.cis not generated in the kernel build but distributed.There is a difference between distributing generated files, and checking generated files into a repository... I do not advocate changing the tarball, just the BK repo behind it.
So you would like to remove defkeymap.c from the bitkeeper repository. Can you briefly explain why?
I am not a bk user so have no feeling for what one would like bk to do.
But it seems to me that if defkeymap.c is only a generated file when no kbd headers have changed, while in the opposite case one needs a private version of loadkeys until the next version of kbd has been distributed, it is easier to regard it as part of the kernel source.
Andries
Quoted 9 lines · Andries Brouwer
Quoted 4 lines · Jeff Garzik
Quoted 2 lines
This shows why
defkeymap.cis not generated in the kernel build but distributed.There is a difference between distributing generated files, and checking generated files into a repository... I do not advocate changing the tarball, just the BK repo behind it.
Quoted 8 lines
So you would like to remove
defkeymap.cfrom the bitkeeper repository. Can you briefly explain why?
I am not a bk user so have no feeling for what one would like bk to do.But it seems to me that if
defkeymap.cis only a generated file when no kbd headers have changed, while in the opposite case one needs a private version of loadkeys until the next version of kbd has been distributed, it is easier to regard it as part of the kernel source.
defkeymap.c is _always_ a generated file. However, some environments lack the capability to generate it (properly).
My motivation is not bitkeeper-specific: I dislike the practice of checking build-generated files into an SCM of any sort. That sort of stuff should be handled by the maintainer, when generating the release patches and tarballs. aic7xxx is another example
Package developers (read: kernel hackers) are expected to have a correct environment to rebuild generated files properly. Package builders are only expected to have a minimal build environment, with stuff like configure scripts, yacc/lex output, defkeymap, and similar things pre-generated from a canonical source (the maintainer).
The GNOME guys recognized this distinction between hackers and builders a long time ago. When you check things out of GNOME cvs, you get _just_ the sources. One must run ./autogen.sh to generate the autoconf/automake/libtool junk needed to actually build successfully.
Jeff
Quoted 2 lines · Jeff Garzik
My motivation is not bitkeeper-specific: I dislike the practice of checking build-generated files into an SCM of any sort.
OK
(Up to a point I can agree with you. On the other hand..
I am a mathematician, and some of my generated files take weeks of computation. Maybe once they are available one no longer wants to regard them as generated files. Something similar holds for files generated by software that is not widely available. Maybe the software is commercial. Maybe it only runs on a different architecture. Or maybe it was a specially patched version. In the case of defkeymap.c (where nothing has changed for over five years), when a key type is added, it is generated by a private version that is not widely available.
For Linus or whoever makes distributions, who does not possess the software required to generate defkeymap.c, it is just a source file.)
Quoted 4 lines · Andries Brouwer
I am a mathematician, and some of my generated files take weeks of computation. Maybe once they are available one no longer wants to regard them as generated files. Something similar holds for files generated by software that is not widely available.
Quoted 8 lines
Maybe the software is commercial. Maybe it only runs on a different architecture. Or maybe it was a specially patched version. In the case of
defkeymap.c(where nothing has changed for over five years), when a key type is added, it is generated by a private version that is not widely available.
For Linus or whoever makes distributions, who does not possess the software required to generatedefkeymap.c, it is just a source file.)
Well, if an auto-generated file in the kernel is not generated by a program that is itself open source, that's IMO a problem. GPL's "preferred form" and all.
Jeff
Quoted 3 lines · Jeff Garzik
Well, if an auto-generated file in the kernel is not generated by a program that is itself open source, that's IMO a problem. GPL's "preferred form" and all.
OK, you two, this is way off topic for a SCSI list.
Since the issue was solved elegantly in 2.6 with the _shipped files, can we agree to drop it (or at least trim back the cc list)?
Thanks,
James
Quoted 1 line · James Bottomley
OK, you two, this is way off topic for a SCSI list.
Thank you, James!
Quoted 5 lines · Jeff Garzik
No user documentation, but feel free to ask me questions. Here's a quick overview:
ata_piix,ata_via-- low-level driver modules
libata -- shared code module for the above
Do you have any plans to support SiI3112 in libata? The current
SiI3112 drivers in the kernel just don't seem to work right on my hardware. :(
Hugo.
Signature · 4 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I am but mad north-north-west: when the wind is southerly, I ---
know a hawk from a handsaw. Quoted 5 lines · Hugo Mills
Quoted 3 lines · Jeff Garzik
No user documentation, but feel free to ask me questions. Here's a quick overview:
Quoted 7 lines
Quoted 2 lines
ata_piix,ata_via-- low-level driver modules
libata -- shared code module for the aboveDo you have any plans to support SiI3112 in libata? The current
SiI3112 drivers in the kernel just don't seem to work right on my hardware. :(
Yes! It should be fairly quick to add Silicon Image SATA support, too.
It's all about finding the time to do it ;-) Hopefully some time in the next week or two...
Jeff
Hi!
Quoted 13 lines
Quoted 4 lines
I am a mathematician, and some of my generated files take weeks of computation. Maybe once they are available one no longer wants to regard them as generated files. Something similar holds for files generated by software that is not widely available.
Quoted 8 lines
Maybe the software is commercial. Maybe it only runs on a different architecture. Or maybe it was a specially patched version. In the case of
defkeymap.c(where nothing has changed for over five years), when a key type is added, it is generated by a private version that is not widely available.
For Linus or whoever makes distributions, who does not possess the software required to generatedefkeymap.c, it is just a source file.)
Quoted 3 lines
Well, if an auto-generated file in the kernel is not generated by a program that is itself open source, that's IMO a problem. GPL's "preferred form" and all.
Actually, that's okay. Source code for proprietary compiler is *still* prefered form for editing.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]