| 1 |
On Thu, 2003-01-30 at 06:37, Chad Huneycutt wrote: |
| 2 |
|
| 3 |
> This scheme essentially means that we use yenta_socket and prefer |
| 4 |
> pcmcia-cs modules, although I think that if you configure a kernel |
| 5 |
> module, it will override the pcmcia-cs module. The only case that isn't |
| 6 |
> handled as I mentioned above is if you *need* the i82365 and ds driver |
| 7 |
> from pcmcia-cs. |
| 8 |
> |
| 9 |
> Thoughts, objections, discussion? |
| 10 |
|
| 11 |
I have to agree with Chad's thorough analysis of the pcmcia-cs |
| 12 |
situation. I was one of the many people who tried (unsuccessfully) to |
| 13 |
contribute a pcmcia-cs ebuild that compiled the drivers regardless of |
| 14 |
whether CONFIG_PCMCIA was set in the kernel. |
| 15 |
|
| 16 |
I think Chad's plan is the right way to go. As far as my laptop is |
| 17 |
concerned, yenta_socket performs *much* better than the i82365 provided |
| 18 |
by pcmcia_cs. When I say perform better, it means it actually works |
| 19 |
after a suspend/resume cycle and doesn't stall the resume process. |
| 20 |
|
| 21 |
As for the problem with needing to remerge pcmcia-cs[-drivers] after a |
| 22 |
kernel recompile, I think that is acceptable. I already have to do that |
| 23 |
with alsa-drivers and other kernel modules (qce-ga) that aren't included |
| 24 |
with the official kernel sources. So I don't think its a big deal. It |
| 25 |
would be good if we could have some sort of metapackage or flag that |
| 26 |
could flag certain packages as "requiring re-merge if a kernel is |
| 27 |
recompiled." |
| 28 |
|
| 29 |
Cheers, |
| 30 |
|
| 31 |
Alastair |
| 32 |
-- |
| 33 |
-=- Alastair Tse -=- LiQUiDx -=- http://www.liquidx.net/ -=- |
| 34 |
PhD Student, Lab of Comm Engineering, Uni of Cambridge, UK |
Archives