Posts tagged ‘ck’

kernel26pierlo

Ho messo su un patchset per il kernel, nulla di incredibile. Si basa sul patchset kamikaze, al quale però ho tolto alcune patch (ad esempio quella per avere lo stack a 4k invece che a 8k, perchè poco compatibile con ndiswrapper, ipw3945 e gspca1 perchè tanto abbiamo il pacchetto con il modulo a parte).

Alle patch di kamikaze ho aggiunto poi qualche piccola patch da ragnarok e le patch presenti in kernel26 (kernel ufficiale archlinux).

Questo è quanto, per il momento. Il tutto è disponibile in aur (kernel+moduli) e nel mio repo personale.

Da notare che ancora non è pronto il supporto a x86_64 (basta preparare il config, ma non ho macchine su cui testarlo), e che il logo è ancora quello del kernel viper, il logo con il tag aggiornato l’ho preparato e verrà shippato con la terza release.

Graditissimi i commenti.

Intervista a Con Kolivas: “Cosa facevo e perchè ho lasciato.”

In questa intervista apparsa su apcmag.com, Kolivas, kernel hacker, racconta minuziosamente le sue idee su linux e i motivi che l’hanno portato ad abbandonare lo sviluppo del suo celebre patchset.

Link all’intervista: http://apcmag.com/6735/interview_con_kolivas

Qualche ritocco in kernel26viper

In attesa di capire che cosa ne sarà di tutto il codice targato -ck, ci sono buone notizie per quanto riguarda kernel26viper. Ho trovato un utente (Mateusz) disposto a occuparsi del testing per l’architettura x86_64: preparerà quindi un config quanto più simile possibile a quello per x86, ovviamente ottimizzato per i 64 bit .

Ho deciso inoltre di riportare come default vesafb al posto di vesafb_tng perchè quest’ultima:

  • non è compatibile con i 64 bit
  • a fronte di pochi vantaggi (maggiore semplicità di configurazione e in certi casi velocità) risulta essere problematica per certi utenti

Ovviamente il kernel rimarrà patchato per supportare vesafb_tng, ma questa non sarà abilitata nel config di default e di conseguenza nemmeno nei binari che metto a disposizione nel mio repo.

Quanto questo cambiamento avverrà, un apposito messaggio nel post_upgrade vi informerà di aggiornare la stringa della risoluzione nel bootloader.

è la fine per il patchset -ck?

Così recita la homepage di Con Kolivas, kernel hacker, autore del noto patchset -ck:

2.6.22-ck1 will be the last -ck ever

La stessa (triste) notizia è riportata anche nel topic del canale IRC di supporto (irc.oftc.net #ck).

L’unica speranza rimane per quanto riguarda l’annuncio ufficiale in ML che Kolivas deve ancora postare. Speriamo in un ripensamento, o se questo è troppo, almeno nella notizia che non tutto il lavoro di Con sia destinato a morire.

[edit]: il messaggio di addio è arrivato, e pare veramente che sarà difficile che Kolivas si riavvicini al kernel, come lui stesso scrive con amarezza:

1. If whatever performance advantage it has is all but abolished compared to
mainline then there is no point maintaining alternate patches to achieve the
same endpoint.
2. All interest I have in kernel development, even out of the mainline
spotlight, has been… abolished (I had nastier words but decided not to use
them.)

In cerca di un nuovo kernel (perfetto, se possibile)

Fino ad pochi giorni fa ho usato per mesi il patchset beyond, ma ora che siamo alla 2.6.21 e beyond è ancora fermo alla 2.6.19 mi infastidisce il pensiero di usare un kernel vecchio (soprattutto vista l’introduzione di alcune robette interessanti, vedi dynticks, nuovo cpu scheduler staircase deadline e qualcos’altro).

Quello che mi interessa principalmente è:

Penso di aver trovato tutto ciò (e altro) in questo patchset: viper

In effetti, PKGBUILD realizzato e kernel compilato, ora questo è quanto:

[pigi@laptop ~]$ uname -r
2.6.21-viper

Peccato solo che linux-phc non funzioni :| , qualsiasi operazione di scrittura io vada a eseguire in /sys/devices/system/cpu/cpu0/cpufreq/op_points_table il processo si blocca.

Ma risolveremo anche questo, sono fiducioso.

Dynticks : la vendetta

kernel_hacking
Apprendo ora con grande piacere che saranno presto integrate nella mainline del kernel delle patch per rendere dinamico il timer del kernel.
“dynticks” era il nome dato da Con Kolivas (kernel hacker) alle sue patch; queste che verranno incluse nel kernel ufficiale sono una versione riscritta quasi da zero (le patch di Kolivas sono state abbandonate qualche mese fa per incompatibilità sui sistemi SMP).
Ne avevo parlato anche qui

Maggiori info:
LWN: Kernel Summit 2006: dynticks