This will usually not work, but not for the reason you're suggesting.
The only CardBus SCSI card that has any support at all is the Adaptec
APA1480A, which uses the stock kernel aic7xxx driver. Unfortunately,
this has been very flaky for me: it works with certain kernels, with
some of my devices, but not others. I've had good success with one of
Doug Ledford's betas, but I don't think that has made it into either
the 2.2 or 2.3 trees yet: maybe he's having trouble with it with some
other cards.
I think you would find that installing any OS from a CardBus SCSI
CD-ROM would be a very hit-or-miss procedure.
> I don't think you realize just how painful that can be for installation,
> and what a headache it is for distributions. It makes testing a few orders
> of magnitude harder, because very few people tend to test the installation
> phase, and right now it is very different for different laptops.
Most of the installation problems I hear about boil down to CardBus
bridge configuration issues, particularly interrupt routing problems,
or less often, IO and memory resource issues. These account for >90%
of the problem reports I get about installation. The only client
driver bug reports I recall in recent months were for the 3c574_cs
driver, which was broken for ages due to lack of info from 3Com.
To some extent, I think this *should* be the headache of people who
put together distributions. That's what they get the big bucks for.
They should at least be able to do some hardware compatibility testing
and provide some hints and hooks for resolving installation problems.
> In contrast, if it was part of the standard kernel, people would test that
> it works correctly every single time they boot up - because there wouldn't
> be any special scripts and other installation-time-only issues. See?
Maybe you just picked a bad example, but you're completely wrong about
this. Since the APA1480A is using a stock kernel driver (the PCMCIA
Makefile pulls the files right out of the current source tree), it is
already getting all this crossover testing you describe, and that
isn't good enough. All the CardBus drivers do this (use driver files
extracted at build time from the kernel source tree) except for the
3c575 driver, for historical reasons, and I will fix that soon.
I don't think any of these issues are really installation-time-only.
The only thing that's special about installation is that you're stuck
with whatever limited tools the distribution maintainers give you.
> The larger problem by far in my opinion is the extra complexity and
> infrastructure that it requires. Which makes sense for PCMCIA to some
> degree, because PCMCIA has all the silly rules and can often need
> extensive help from user space in the form of configuration information.
> But doesn't really make much sense for cardbus (and thus all modern
> laptops) that is a pretty clean architecture and wouldn't really need some
> of the extra code.
I think you're overestimating the gap between PCMCIA and CardBus a
bit. The funny IO and memory configuration stuff for PCMCIA is really
not that hard to get right, and is reasonably stable and solid. Once
devices are configured, PCMCIA and CardBus are roughly equally easy to
deal with. But CardBus bridges are nontrivial to configure correctly
from scratch. It is still not uncommon for laptops to require vendor
specific Windows drivers to support CardBus... meaning that the BIOS
cannot be relied on to just set everything up correctly.
> Even if the copyright _allows_ me to use other peoples code, I always want
> to be extra sure that it's not just about being legally allowed, it's also
> about being Ok on a personal level. I've gotten the feeling that you
> wouldn't have wanted that..
I've obviously not done much to facilitate it. I guess part of it has
been for my convenience, and part of it is a control issue. I like
being lord of my domain, which isn't a good reason, but one that you
could probably appreciate. If PCMCIA were in the kernel tree, it
would make some things harder for me... and some things easier. I'd
probably not need to be so on top of minor kernel interface changes,
at the expense of having to cope with version skew between the kernel
and user-mode PCMCIA tools and configuration files.
-- Dave Hinds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/