Re: [gentoo-user] kernel 3.8 and external drivers

[Volker Armin Hemmann]

Am 11.03.2013 14:00, schrieb Yuri K. Shatroff:
> On 11.03.2013 03:05, Daniel Wagener wrote:
>> On Sun, 10 Mar 2013 21:53:42 +0100
>> Volker Armin Hemmann <volkerarmin@××××××××××.com> wrote:
>>
>>> Am 10.03.2013 19:28, schrieb Daniel Wagener:
>>>> Hello,
>>>>
>>>> I ran into some trouble about an hour ago…
>>>>
>>>> My workstation has an onboard Realtek Ethernet which only works
>>>> with the r8168 driver. Unfortunately, this driver is not in the
>>>> kernel, but available to be compiled as a kernel module. (I guess
>>>> because of som patents) That worked for quite some time, until i
>>>> thought "hey, you got an hour of time, your workstation is still on
>>>> 3.7.4, why don't you just upgrade it to 3.8.2?" So I did, only to
>>>> find out that Linus and his friends changed the way drivers are
>>>> initialized… (__devinit got unsupported for example)
>>>>
>>>> Of course, the guys who wrote that r8169 have not changed their
>>>> code yet.
>>>>
>>>> tl;dr:
>>>> My network is broken since 3.8.0.
>>>>
>>>> So for an immediate fix I am emerging 3.7.10 (since emerge
>>>> --depclean deleted the Kernel source when it found the source fo
>>>> 3.7.8 which got removed as soon as 3.8.2 was emerged…) to get it
>>>> working again. For the long run im thinking of buying a PCI(e) card
>>>> with Kernel support. Or maybe, if I find some time I will fix the
>>>> driver myself.
>>>>
>>>> My question now is:
>>>> Who should I talk to so something like this does not happen again?
>>>> A certain gentoo dev, who could issue warnings on emerging kernels,
>>>> something like excerpts from the changelog? Myself, because I
>>>> missed what I described above? The devs of the r8169?
>>>> Linus & co for breaking things?
>>>> Myself bcause I forgot something else?
>>>> Realtek?
>>>> Or someone completely different?
>>>>
>>> so, you are using a superfluous external driver. Despite the fact that
>>> external drivers are prone to breaking you insist on using the latest
>>> kernel, instead using the latest kernel of one of the stable kernel
>>> series like 3.4. To add insult to injury you remove kernels after
>>> installing instead of after testing.
>>
>> well… I guess that sums it up… :(
>>
>
> sorry for breaking in, but...
> (to Volker Armin Hemmann)
>
> 1. If this driver is superfluous as you say, then why does it ever
> exist in portage?

because it exists? gnome is there too. Or systemd AND openrc. mrxvt,
rxvt AND urxvt.
>
>
> 2. Since it does exist, then probably it would be much nicer to user
> to show him a notice when he (user) tries to compile it on a kernel
> which has native support for the device, or moreover an unsupported
> kernel installed, than blame user for that?

no, this is gentoo. You are supposed to do your homework. No training
wheels.

>
> 3. Why does the ebuild *not* check for supported kernel version or
> breaking APIs/ABIs?

why should it? See above. You can't know if in the future something
might change.
>
> 4. How and why would you expect to force all users to grep thru kernel
> src in search for a driver they might need, especially when the
> portage explicitly lists this driver? Also sometimes kernel drivers'
> description is not quite consistent and it is not easy to figure out
> whether it supports exactly yours card/chip/device, or moreover find
> it by grep.

All kernel source? grep? Nope. Just reading a bit of help text. Maybe
using google. Doing it once. Then you have a working setup you can use
for the rest of eternity (or the next couple of years...)

> 5. After all, linux and gentoo in particular are *not*
> developer-only-oriented systems, and it is up to maintainers or
> whomever to make them more user-friendly. Yes, it is not fair of a
> user to blame someone for breaking APIs etc. but neither it is fair to
> blame the user for not knowing everything as I bet nobody knows
> everything about linux kernel.

oh, so gentoo is for ubuntu users? Well, why not use ubuntu in the first
place?

But I feel generous right now. You might have a point there. That does
not invalidate the 'remove kernels before testing' criticism from the
list nor does it solve the 'insisting to use the latest kernel release
instead of stable series' problem.