Na luzie > Rozmowy w toku
Źródła udostępnione w Githubie - dyskusja
sir_lucjan:
Owszem, można coś zmienić, można coś naprawić - tego nie neguję. Problemem jest kwestia czasu (lub dokładniej jego braku). Jeśli ktoś zechce pomóc mi w tej
kwestii, to być może problem uda się rozwiązać. Jest to nawet wielce prawdopodobne. Czasowe rozwiązanie problemu jest bardzo słuszne - nie zaprzeczę, jednak zrobienie tego w pojedynkę na chwilę obecną jest nieco nierealne. Zatem jak znajdziesz czas, możesz pomóc w rozwiązaniu problemu - z pewnością wiele to ułatwi. Dotyczy to także innych użytkowników - im nas więcej, tym lepiej! Samodzielnie rozwiązanie problemu w tym momencie przekracza nieco moje możliwości "czasowe" - nie mam aż tyle wolnego czasu, by nad tym przysiedzieć. Nie jest to spowodowane moim lenistwem czy złośliwością.
Uściślijmy - chodziło Ci o to, że NUMAdisable to zły pomysł czy usunięcie tego wpisu jest niezbyt dobrym wyjściem?
pavbaranov:
--- Cytat: sir_lucjan w Maj 07, 2015, 13:46:08 ---Owszem, można coś zmienić, można coś naprawić - tego nie neguję. Problemem jest kwestia czasu (lub dokładniej jego braku). (...) Nie jest to spowodowane moim lenistwem czy złośliwością.
--- Koniec cytatu ---
Lucek - odległy jestem zarzucania Ci lenistwa, czy złośliwości. Ot, po prostu Twoje słowa nasunęły mi ogólną refleksję na temat paczek w Archu.
--- Cytat: sir_lucjan w Maj 07, 2015, 13:46:08 ---Uściślijmy - chodziło Ci o to, że NUMAdisable to zły pomysł czy usunięcie tego wpisu jest niezbyt dobrym wyjściem?
--- Koniec cytatu ---
Pozostaw tak jak było dotychczas. Wszystko - jak na razie - wskazuje na to, że jest to lepsze "ogólnie" rozwiązanie, a wyłącznie obecnie są z tym jakieś problemy, które dotyczą niewiadomego rodzaju procesorów, w dodatku wyłącznie jednego producenta. Nadto ilość nieobsługiwanych procesorów zmienia się w czasie. Nie wiemy również, czy problem dotyczy wyłącznie optymalizowanych kerneli, czy też również generic. IMO lepiej jest dać PKGBUILD w dotychczasowej wersji (albowiem jest on OTB do zastosowania przez wszystkich posiadaczy platform AMD oraz części Intela i prawdopodobnie również wszystkich posiadaczy procesorów innych niż wymienione), a jedynie w PKGBUILDzie, bądź w jakiejś notce na AUR czy gicie opisać, że:
- użytkownicy niektórych procesorów Intela być może muszą wyłączyć NUMAdisable,
- -"- być może muszą zbudować kernel generyczny,
- wszyscy - w przypadku 4.0.2 - muszą wyłączyć wirtualizację (albo pozostać na dotychczasowym kernelu).
Wydaje się, że taka informacja jest jasna i czytelna i umożliwia odpowiednie zbudowanie kernela, który będzie pracować. Wraz z 4.0.2 - jak wynika z wątku w BBS coraz więcej procesorów Intela jest obsługiwanych. Nie wiadomo zatem nawet, czy nie jest to jakiś błąd upstreamowy, który po prostu wraz z BFSem się ujawnia. Zwróć uwagę, że pod 4.0.2 Con nie zrobił nowego BFS, a problem - przynajmniej w części - został zażegnany. Cóż, budując kernel z AUR każdy musi mieć świadomość tego co robi.
W AUR myślę, że dalej - tak jak robisz dotychczas - 3.19.x. Ta wersja ma być wspierana aż do czasu, kiedy problemy z 4.x (upstreamowe) zostaną wyeliminowane. Jednocześnie, kolejne wersje 3.19 są wzbogacane o wszelkie poprawki związane z bezpieczeństwem, są usuwane te same błędy tkwiące we wspólnym kodzie 3.x i 4.x itd.
sir_lucjan:
Postanowiłem przyjąć takie rozwiązania.
Kernele w AUR:
- linux-bfq - wersja 4.0. BFQ nie sprawia większych problemów. Jeśli pojawią się zgłoszenia o problemach podobnych do tych w linux-ck obniżę numer wersji do 3.19.
- linux-bfs, linux-bridge-pl, linux-uksm-ck - wersja 3.19.X. Dopóki problemy z patchem BFS nie zostaną zażegnane, nie podbiję numeru wersji. Zwłaszcza, że wersja 4.0.2 nie buduje się poprawnie na dostarczanym configu (musiałbym wyłączyć xen a to kiepski pomysł).
- linux-uksm - wersja 3.19.X. Wersja 4.0 (4.0, 4.0.1, 4.0.2) budują poprawnie, jednak sam patch jest w wersji beta i dopiero kiedy twórca wyda oficjalną wersję, podbiję w AUR. Chyba, że wersja oficjalna nie ukaże się do czasu uzyskania przez 3.19 statusu EOL - wtedy będę zmuszony podbić numer wersji.
Kernele w Githubie:
Sekcja "aur"
- linux-bfq, linux-uksm - wersja 4.0.2. Buduje prawidłowo.
- linux-bfs, linux-bridge-pl, linux-uksm-ck - wersja 4.0.1 - z racji tego, że 4.0.2 nie buduje się na dostarczanym configu - jak wspominałem, wycięcie Xen w domyślnym configu to kiepski pomysł.
Sekcja "kernelrc"
Póki co (na dzień 7 maja 2015) status podobny jak w sekcji "aur".
pavbaranov:
--- Cytat: sir_lucjan w Maj 07, 2015, 15:02:57 ---Postanowiłem przyjąć takie rozwiązania.
--- Koniec cytatu ---
To na Twoim miejscu, napisałbym jeszcze 1-2 zdania w odpowiednich miejscach, dlaczego przyjąłeś takie rozwiązania
--- Cytat: sir_lucjan w Maj 07, 2015, 15:02:57 ---Kernele w Githubie:
- linux-bfs, linux-bridge-pl, linux-uksm-ck - wersja 4.0.1 - z racji tego, że 4.0.2 nie buduje się na dostarczanym configu - jak wspominałem, wycięcie Xen w domyślnym configu to kiepski pomysł.
--- Koniec cytatu ---
Dopisałbym, że wersja 4.0.2 jest możliwa do zbudowania, ale z wyłączoną wirtualizacją (jej wyłączenie, dla osób, które nie korzystają z wirtualizacji wcale nie jest kiepskim pomysłem, ale wyłącznie przy budowie własnego kernela).
I niech ludzie robią co chcą.
sir_lucjan:
I tu jest problem - dasz starszy kernel, będzie gadanina, że nie ma nowego. Dasz nowy, będzie marudzenie, że nie buduje a wirtualizacja jest akurat potrzebna. Nie dogodzisz każdemu :)
Nawigacja
[#] Następna strona
Idź do wersji pełnej