From: Jeff Garzik <jgarzik@pobox.com>
To: Andrew Chew <achew@nvidia.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH 2.6.7] new NVIDIA libata SATA driver
Date: Wed, 16 Jun 2004 21:47:16 -0400 [thread overview]
Message-ID: <40D0F824.8010108@pobox.com> (raw)
In-Reply-To: <DCB9B7AA2CAB7F418919D7B59EE45BAF043984B6@mail-sc-6-bk.nvidia.com>
Andrew Chew wrote:
>>From: Jeff Garzik [mailto:jgarzik@pobox.com]
>
>
>>If silicon isn't available yet, let's just remove those PCI
>>IDs. That way we can ensure that these are libata only,
>>without two drivers sharing the same PCI ids.
>
>
> If that's the case, I'd rather the CK804 and MCP04 SATA device IDs be
> added to sata_nv, since we want distributions to support these SATA
> controllers when silicon does become available.
OK
>>>>Removing IDs from amd74xx.c is a bad idea,
>>>>it breaks boot on systems already using these IDs.
>>>
>>>I assume these systems will be able to boot using the libata
>>>subsystem. Is that a bad assumption?
>>
>>They can, but consider a system that uses 2.6.7 (IDE driver)
>>then boots into 2.6.8 (libata driver): the drives move from
>>/dev/hdX to /dev/sdX. That breaks stuff not using LABEL= in
>>bootloader config and fstab.
>
>
> That's true. I kinda chalk this up as an inevitable kernel upgrade
> issue (they'll be getting support for NVIDIA SATA under libata with
> eventual device hotplug support, at the cost of some system
> reconfiguration). Is there a good solution?
None really, other than trying to make sure we only add new SATA
hardware support under libata.
Most users with Red Hat or SuSE or whatever don't know enough other than
"I booted the new Fedora 2.6.x kernel, and it panic'd when it tried to
mount root filesystem"
Your patch represented the _ideal_, but unfortunately once added to the
IDE driver, those PCI ids should not be removed in the middle of a
stable kernel series. If both drivers were /dev/sdX, or /dev/hdX,
moving the PCI ids to another driver wouldn't be as big of a deal.
Overall... no worries. I have to deal with this issue for a couple
other chipsets, so I'll handle them all at the same time.
Jeff
next prev parent reply other threads:[~2004-06-17 1:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-17 1:35 [PATCH 2.6.7] new NVIDIA libata SATA driver Andrew Chew
2004-06-17 1:47 ` Jeff Garzik [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-17 1:28 Andrew Chew
2004-06-17 1:19 Andrew Chew
2004-06-17 1:22 ` Jeff Garzik
2004-06-17 0:17 Andrew Chew
2004-06-17 1:12 ` Bartlomiej Zolnierkiewicz
2004-06-17 1:20 ` Jeff Garzik
2004-06-17 2:49 ` Markus Kossmann
2004-06-17 3:13 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40D0F824.8010108@pobox.com \
--to=jgarzik@pobox.com \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=achew@nvidia.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox