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
On 09.13, Jeff Garzik wrote:
> 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.
--
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))
On 09.13, Jeff Garzik wrote:
> 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. :)
>
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.
--
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))
On Sat, Sep 13, 2003 at 10:56:52PM +0200, J.A. Magallon wrote:
>
> On 09.13, Jeff Garzik wrote:
> > 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.
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
On Sat, Sep 13, 2003 at 11:13:32PM +0200, J.A. Magallon wrote:
>
> On 09.13, Jeff Garzik wrote:
> > 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. :)
> >
>
> 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.
On Sat, Sep 13, 2003 at 05:28:49PM -0400, Jeff Garzik wrote:
> On Sat, Sep 13, 2003 at 10:56:52PM +0200, J.A. Magallon wrote:
> > 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
Andries Brouwer wrote:
> This shows why defkeymap.c is 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
On Sun, Sep 14, 2003 at 01:26:21PM -0400, Jeff Garzik wrote:
> > This shows why defkeymap.c is 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
Andries Brouwer wrote:
> On Sun, Sep 14, 2003 at 01:26:21PM -0400, Jeff Garzik wrote:
>
>
>>>This shows why defkeymap.c is 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.
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
On Sun, Sep 14, 2003 at 04:09:44PM -0400, Jeff Garzik wrote:
> 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.)
On Sun, 2003-09-14 at 16:36, Jeff Garzik wrote:
> 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
Andries Brouwer wrote:
> 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.)
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
On Sun, Sep 14, 2003 at 04:38:41PM -0500, James Bottomley wrote:
> OK, you two, this is way off topic for a SCSI list.
Thank you, James!
Hugo Mills wrote:
> On Sat, Sep 13, 2003 at 05:38:28PM -0400, Jeff Garzik wrote:
>
>>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. :(
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
On Sat, Sep 13, 2003 at 05:38:28PM -0400, Jeff Garzik wrote:
> 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.
--
=== 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.
Hi!
> >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.)
>
> 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
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]