[LWN Logo]

Date:	Thu, 3 Jun 1999 10:52:44 -0700
From:	David Hinds <dhinds@lahmed.Stanford.EDU>
To:	Linus Torvalds <torvalds@transmeta.com>
Subject: Re: 2.3 wish: integrate pcmcia into mainstream kernel

On Wed, Jun 02, 1999 at 11:18:51PM -0700, Linus Torvalds wrote:

> What that means, is that basically _all_ the machines I'm in the least
> interested in have a floppy that is behind either USB or CardBus. And in
> almost all cases the CD is CardBus, although I expect that in a few years
> people will just take DVD so for granted that eventually the CD will be
> built-in even in the small ones. 
> 
> But in the meantime, that means that just about every single interesting
> ("interesting" admittedly being my personal opinion - I don't understand
> how people accept a 6+ lbs laptop these days, but people obviously do) 
> laptop coming out within the last few months or in the next year is going
> to be hard to install Linux on unless something changes.
> 
> Because obviously it seems to be really painful for people to try to cram
> in all the PCMCIA tools on a initrd disk on a CD. At least nobody does it: 
> it seems to expand the size of the required tools enough that both SuSE
> and RedHat require that Linux be able to read a floppy. Which you
> currently can't do if the floppy is connected through a PCMCIA device. 

Finally, a technical issue that is not a strawman!!  Linus, why didn't
you start out by describing your problem THIS way (and maybe emailing
me about it privately, since it obviously seems important to you),
instead of vaguely talking around the problem, insinuating that
someone else should redo PCMCIA, and telling me that my work sucks?
You might have found a more receptive audience, and I would have bent
over backwards to deal with it.

So, let's look at this issue: installation from a bootable PCMCIA IDE
device is difficult, because the most common bootable images don't
include PCMCIA support any longer, due to space constraints.

Background: The RH6.0 standard boot image is 98% full, with 35K free:
space for maybe one or two additional drivers.  The core PCMCIA
components (pcmcia_core.o, ds.o, i82365.o, tcic.o, cardmgr) plus the
ide_cs driver take up about 115K uncompressed, 70K compressed.  The
overhead for config files is minimal if we are only handling IDE: say
1K for the rc script, and just a couple lines for a config file for
IDE devices.  Bottom line: 70K > 35K, it won't fit.

Possible solutions:

o Say we removed the user mode component of PCMCIA.  How much space
  could be saved?  cardmgr is 35K stripped, 16K compressed.  Most of
  that is for parsing config files and running other scripts, so say
  we could save all of it.  We'd need to add in some new code to link
  up cards with drivers, but we'll ignore that for now.  We could save
  another 18K compressed by dumping the tcic.o module, turning off
  32-bit card support, and removing memory card support.  So, with
  tighter kernel integration (and turning off some features at compile
  time), we might just get to where it could be squeezed in.

o A hack.  The issue is handling a card that is configured already by
  the BIOS as a boot device.  So, we just have a little module that
  checks each socket for a powered-up card that looks like an IDE
  device, and registers it.  I think this could be done in about 100
  lines of code.

o Say we rewrote PCMCIA from scratch.  Space savings?  Unknown.  I do
  not believe that there is a lot of fluff in the current system, and
  I think you would have a tough time doing better without sacrificing
  functionality.

The first option has the advantage that the user-mode-independence
might be very useful in other cases, such as embedded systems.  It can
be done: I did it, in fact.  I wrote a kernel module replacement for
cardmgr a couple years ago, and set things up so PCMCIA could be
linked into the kernel.  I decided not to use it, because initrd
seemed to be a better solution to the problems I was dealing with at
the time.  But it can easily be done in the current PCMCIA framework:
I could add this functionality to the ds.o module in a day.

There are some downsides to the first option.  Putting all card
recognition in kernel space would be bloated, ugly, and unmanageable.
Bad idea.  On the other hand, I think a tiny generic enabler that
could handle 95% of all serial, IDE, and memory cards (the ones that
don't have broken configuration info) would be reasonable.  This would
mean that there would be some disconnect between what things worked in
the basic installation environment, and what worked in a normal system
once cardmgr is running.  But I think it's a reasonable trade-off in
this case.

Another downside to the first option is that I'm not sure it would
solve the original problem.  Fitting everything into that 35K on the
RH6.0 boot image would still be hard.  And what happens when next
month's kernel is 2K bigger?  Something has to give.  It is a
historical accident that, right now, this might make a difference.

At first, I thought the second option would be the most expedient, but
it would require more hacks for clean transitions when regular PCMCIA
drivers get fired up, so now I think this would be a bad long term
solution.

I'll ignore the third option: if someone wants to rewrite PCMCIA, they
can go for it.

As an aside, you may think this is a show-stopper problem, but I can
tell you that out of thousands of PCMCIA support issues (and hundreds
of specifically installation related questions), this is the *first
time* I can recall seeing this particular issue raised.  And to answer
one of your earlier questions, yes, I often get email from people who
could not even get Linux installed, due to PCMCIA issues.  You are
certainly correct that it is a problem that should be addressed, but
it has somehow managed to remain below my radar.  Why?  Maybe it
reflects the relative numbers of people who encounter each type of
problem, or their relative levels of sophistication, or some kind of
reporting bias.  I don't know.  But I don't deliberately ignore
issues.

> This is also why I'm not all that concerned about old laptops. They all
> have a built-in floppy, or at least close enough to not be an issue. It's
> the new ones where the size constraints are becoming so painful that a
> floppy simply isn't even possible any more that need the most help. 

Not true.  There were laptops (Compaq Elite series, I think) that had
PCMCIA floppies, and I tweaked the PCMCIA package to deal with it.
That was especially painful, because their floppies also use
undocumented host-side hardware to do DMA over PCMCIA.

PCMCIA floppy support in general is painful because of the DMA issue.
We have a PCMCIA floppy driver, but it requires a fairly large patch
to the kernel floppy driver, and I don't think that can be integrated
into a general purpose kernel at this time.

> Hint: they don't. And PnP isn't the issue, never has been.

Fine, it isn't *your* issue.  I can say that based on the problem
reports I deal with every day, that it is *my* issue, and I'd have
distinctly more free time if it went away.  Again, my only data source
is number and variety of problems reported, and the underlying
statistics might be very different.  But that's what I see.  And
unless you're omniscient, I think my data is probably more
comprehensive than yours.

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