| 1 |
Et ça continue... |
| 2 |
|
| 3 |
What KV_OUTPUT ends up being set to is ultimately the factor dictating which |
| 4 |
kernel setup we've found, and which method of building will be used. Here's a |
| 5 |
table showing the three different kernel configurations, and what these two |
| 6 |
variables will be set to after kmod_src_unpack() is called. |
| 7 |
|
| 8 |
Est-ce que quelqu'un comprend de quelles variables il s'agit ? Je ne vois que |
| 9 |
KV_OUTPUT sur le tableau... |
| 10 |
|
| 11 |
Le mercredi, 14 Avril, 2004 22:03, Olivier Fisette a écrit : |
| 12 |
> Bonjour, |
| 13 |
> |
| 14 |
> Je traduis en ce moment 2.6-koutput-dev, et j'ai de la difficulté à |
| 15 |
> comprendre le paragraphe suivant : |
| 16 |
> |
| 17 |
> kmod_src_unpack() works very hard to figure out how the driver being built |
| 18 |
> should be handled. In particular, it handles the two different 2.6 build |
| 19 |
> methods very well. If the new method using koutput is detected, this will |
| 20 |
> not be done, and the patch in KMOD_KOUTPUT_PATCH will be applied if it |
| 21 |
> exists. After kmod_src_unpack() has been called, there are a plethora of |
| 22 |
> variables available for use elsewhere in the ebuild. |
| 23 |
> |
| 24 |
> Qu'est-ce que ce « this » qui ne sera pas fait ? Suis-je le seul à être |
| 25 |
> dérouté par cette phrase ? |
| 26 |
> |
| 27 |
> Merci de m'éclairer, |
| 28 |
|
| 29 |
-- |
| 30 |
Olivier Fisette (pilos) |
| 31 |
|
| 32 |
-- |
| 33 |
gentoo-doc-fr@g.o mailing list |
Archives