saq: SPECS xawtv.spec

[Tomasz Kłoczko]

On Tue, 7 Aug 2001, Paweł Sakowski wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> On Mon, 6 Aug 2001, Tomasz Kłoczko wrote:
> 
> > Nadal nie mamy rozwiązanej kwestii z lirc (smp<->up) i w zwiazku z tym też 
> > nie ma bibliotek do lirc. Chyba na razie możnaby na bcond wyłączyć 
> > wsparcie do lirc (?).
> 
> Przyjrzałem się bliżej sprawie i okazuje się, że miałeś rację. Użyta w 
> jądrze konstrukcja locków (wymagająca znajomości ustawienia CONFIG_SMP) 
> powoduje, że moduły używające spinlocków (w tym lirc_dev, svgalib_helper 
> chyba nie):
> 
> - po skompilowaniu z SMP nie zadziałają na UP
> - po skompilowaniu na UP mogą się nie zablokować kiedy trzeba na SMP
> 
> A więc moduły muszą istnieć w dwóch wersjach. Widzę następujące sposoby, 
> jak to zrobić:
> 
> - za jednym rpm -bb przebudować moduły dla SMP i UP, podmieniając 
> ustawienie CONFIG_SMP w .config.
> 
> - budować dwa razy, z różnym /usr/src/linux/.config

Raczej to pierwsze. /usr/src/linux/.config jest dołaczany pro forma i 
jawnie z zawartości tego pliku nic nie powinno korzystać. Po za tym w 
przypadku kernel-headers /usr/src/linux/.config nie jest wogóle używany.

> Drugie rozwiązanie wydaje mi się porządniejsze, chociaż wprowadza pewne
> zamieszanie. Trzeba przygotować dwa zestawy kernel-source z różnymi
> .configami, ewentualnie wydzielić .config do osobnego pakietu (np.  
> kernel-config-{smp,up}, wymagany przez kernel-source). W tej chwili w
> kernel-source leży config dla SMP. Poza tym trzebaby wreszcie rozwiązać
> kwestię budowy na builderach dla różnych jąder (moja ostatnia propozycja w
> tej sprawie przeszła bez echa).
> 
> Przyszło mi do głowy jeszcze jedno rozwiązanie (radykalne): zrezygnować z
> jądra UP. Jądro SMP też działa na UPach, a rozwiązałoby to parę spraw.  
> Wady:
> 
> - jądro większe o ok. 49kB
> - "the kernel will run on many, but not all, singleprocessor machines"
> - "On a singleprocessor machine, the kernel will run faster if you say N 
> here"

Na coś takiego nastawiony jest przykładowo kernel z Solarisa. W ogólnym 
przypadku ma to sens. W szczególności nie koniecznie. Do póty do póki 
utrzymanie rozdziału UP/SMP będzie w miarę proste raczje od tego modelu 
nie bęziemy odchodzić.

Ciekawe czy ludzie od lirc nie próbują przypadkiem czykować patcha na 
regularny kernel z wsparciem do lirc. O ile nie mieliby oni nic przeciwko 
czemuś takiemu to nawet chetnie chyba bym pomógł w skompletowaniu takeim 
poprawki którą najpierw moglibyśmy używać w PLD, a ostatecznie weszłaby 
ona w oficjalne źródła. Na dłuższą mete to podejście wydaje mi się takim 
które przysparzałoby najmneij kłopotów i upraszczało możliwie mocno 
zagadnienie. Sam pakeit lirc mógłby wtedy zawierać tylko źródła 
biblioteki i odpadłaby zabawa z dual pakeitami smp/up.

Ma ktoś kontakt z tymi ludźmi i/lub widział coś na ten temat na liście 
lirc ? Jakby ktoś zainteresowany lirc mógł nawiązać taki bliższy kontakt 
z ludźmi od lirc to byłoby dobrze.

To samo podejście dobrze by było zastosować i do innych rzeczy jak svga 
helper.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*