Newsgroup: it.comp.os.dibattiti
Titolo: Padellium!

               P A D E L L I U M!
settimanale di satira e costume su I.C.O.D.
   <<< rigorosamente OFF TOPIC >>>
In questo numero:
------------------------------------------------------------------
Le massaie installano freeBSD:
 Pogoboy: "un floppy e un cd in ogni dispensa!"
Scoperto il ganzo della sistemista ninfomane di IBM:
 pare che sia tale Linus Torvalds, tutti i particolari in cronaca.
L'angolo del bolscevico:
 Fedrox se ne frega dell'I/O asincrono:
 "l'importante è sincronizzarsi contro qualcuno!"
Ballmer la fa franca in tribunale:
 "spezzeremo le reni alla Sun, altro che spezzatino!"
Gli scoop di Padellium!:
 "Tutti ce l'hanno, perchè io no?"
  Linus non si rassegna e promette una major release coi fiocchi!
  (asincroni)
Bill Gates si confessa:
 "da piccolo volevo scrivere Linux,
  mi hanno fatto odiare il mondo ed è venuto fuori windows ME".
Gli esperimenti del Dottor Mistero:
 "volevo installare freeBSD 4.7 e ho trovato le iso di 4 cd:
  la fuffa avanza anche nel tempio di Unix?"
 Qualcuno gli spieghi che non capisce un cazzo!
------------------------------------------------------------------

    <<< rigorosamente OFF TOPIC >>>
Simpatica iniziativa.
Saluti.

   la fuffa avanza anche nel tempio di Unix?"
Uno non bastava? =)

 Uno non bastava? =)
E gli altri tre a che servono?
saluti quadruplici

  "l'importante è sincronizzarsi contro qualcuno!"
Vorrei riportare la discussione sull'I/O asincrono
un pochetto sul lato tecnico.
Cioe`, mi interesserebbe sapere quale sarebbe la
differenza tra l'implementazione in kernel space
oppure in user space, prestazioni (forse) a parte.
bye,
-- 
  Piergiorgio Sartor

 oppure in user space, prestazioni (forse) a parte.
La differenza sta nel non dover implementare codice che si occupa della
gestione dell'i/o in maniera asincrona (ad es. con un thread separato) e 
di demandare il compito alle funzioni di i/o del kernel.
-- 
Vincenzo

 oppure in user space, prestazioni (forse) a parte.
Beh, prestazioni a parte non direi, un context switch non rasserena la vita,
nè ai processori nè alle loro cache.
saluti a ring 0

 di demandare il compito alle funzioni di i/o del kernel.
Funzioni di libreria standard, alla fine,
mica che devo scrivermi tutto ogni volta...
bye,
-- 
  Piergiorgio Sartor

 nè ai processori nè alle loro cache.
Il fatto che sia in kernel space non ti salva
dal cache trashing.
Comunque, la parte in attesa viene "sputata"
fuori da processo corrente.
Riguardo al contex switch, beh anche questo
dipende, forse per un processo potrebbe esserci,
magari per un thread no.
Inoltre avere la cosa in user space consente
maggiore flessibilita`.
Dato che il programma deve comunque essere
consapevole della possibilita` dell'I/O asincrono
(per sfruttarlo), avere controllo sui thread che
aspettano consente alcune cosette piu` sofisticate,
ad es. avere I/O asincrono a livello di file, e
non di device...
bye,
-- 
  Piergiorgio Sartor

 non di device...
Parliamo di file i/o asincrono? Bella cosa da realizzare, ma non credo che
ogni programmino in c da quattro righe se la debba scrivere per conto suo.
saluti a ring 0

 ogni programmino in c da quattro righe se la debba scrivere per conto suo.
No, non necessariamente, esistono le librerie...
Il problema e`:
conviene avere un meccanismo di I/O asincrono
hardcoded nel kernel oppure conviene usare i
thread/processi ed averlo in user space? (Sottinteso
in libreria, mi pare chiaro).
bye,
-- 
  Piergiorgio Sartor

 in libreria, mi pare chiaro).
Sottintendevo anch'io che comunque hai una libreria di funzioni da qualche
parte, ovvio.
Ma per operazioni critiche come l'i/o, un context switch non è certo un
toccasana.
Tu mi dirai, ma io voglio fare file i/o asincrono; giustissimo, anche quello
può essere demandato a un driver che gira a ring 0 (per esempio ntfs lo fa).
Secondo me il problema è minimizzare il context switching; quando microsoft ha
portato i drivers video a ring 0 tutti (me compreso) hanno storto la bocca; ma
adesso quel kernel fa girare anche i giochi.
Per esempio (spero di non dire una cappellata, non ricordo bene i termini
della questione) il problema dell'i/o asincrono in user space si presenta in
linux quando devi scrivere uno sniffer (o ids, a scelta); apposta per questi
scopi è preferibile usare nt o bsd che fanno tutto (promiscous mode) a ring 0.
saluti a ring 0

 scopi è preferibile usare nt o bsd che fanno tutto (promiscous mode) a ring 0.
Non so i dettagli di questo particolare esempio,
solo una cosa: ring 0 si riferisce _solo_ alle
architetture x86, in generale si parla di supervisor
mode... Giusto per evitare confusione.
bye,
-- 
  Piergiorgio Sartor

 E gli altri tre a che servono?
Altri package disgraziati, mirror del CVS, fuffa optional?

 in libreria, mi pare chiaro).
Il grosso problema credo sia fare il debug di un'applicazione che 
si gestisca l'async i/o con thread o processi separati. Oltre al 
fatto che in qualche modo ci sono overhead dovuti alla sincronizzazione 
dei processi (o thread).
-- 
Vincenzo

 un mattone monolitico.
Uhm, credo di aver capito dov'è che non mi spiegavo bene.
Nel caso del kernel di NT, non ci sono context switching a livello kernel, 
anche se NT non si può definire propriamente monolitico.
In ciò consiste (a mio avviso) il vantaggio; hai qualcosa di simile a un 
microkernel, perchè non devi mica linkare nel kernel tutti i drivers che ti 
servono; al contempo tutte le componenti del kernel girano nello stesso 
spazio di indirizzamento, quindi il context switching non è necessario.
saluti cooperativi

 Altri package disgraziati, mirror del CVS, fuffa optional?
Insomma, per avere freeBSD+KDE mi basta il primo cd?
saluti economici

 Insomma, per avere freeBSD+KDE mi basta il primo cd?
Credo che ti avanzi pure Gnome2 & il resto della fuffaglia colorata...

 spazio di indirizzamento, quindi il context switching non è necessario.
Questo somiglia molto all'approccio RTLinux, in
cui i processi RT girano a livello kernel.
E` accettabile solo se si necessita` di essere
RT, altrimenti e` un rischio troppo alto.
Eppoi hai sempre il solito problema, cioe`
parti da uK e crei un monolite o viceversa.
Ad es. avere le syscall preeptable e` comodo,
ma significa avere uno scheduler (magari
semplificato) per il kernel (quindi contex
switch). Come conseguenza il codice kernel
deve diventare "rientrante" e sottostare a
tutta una serie di "regole" di convivenza.
Questo complica le cose e non e` detto che,
alla fine, migliori le prestazioni.
Oppure si limita "chirurgicamente" la possibilita`
di preemption e si ottiene un sottosistema di
quello che era il target originale.
Quindi, ancora, mi pare che sia una soluzione
(uK) che l'altra (monolitico) tendano a
viaggiare l'una verso l'altra e persino a
passarsi per raggiungere l'estremo opposto e
magari tornare indietro...
bye,
-- 
piergiorgio

 dei processi (o thread).
Beh, il problema prestazioni e` sempre
presente, in questi casi.
bye,
-- 
piergiorgio

 presente, in questi casi.
Comunque in un link gia` postato:
http://www.atnf.csiro.au/people/rgooch/linux/docs/io-events.html
si evidenzia il limite di utilizzare poll() su sistemi con grossi carichi.
-- 
Vincenzo

 parti da uK e crei un monolite o viceversa.
Continui a parlare di kernel monolitico, ma il kernel di NT non è affatto
monolitico.
monosaluti

 monolitico.
Non lo e` per design, ma lo diventa alla
fine, quando cacci tutto a livello kernel
per aumentare le prestazioni.
Questo non e` un problema di NT, ma in
generale, ad es. quando su Linux hanno
messo nel kernel il server http, stesse
ragioni: prestazioni.
bye,
-- 
  Piergiorgio Sartor

 si evidenzia il limite di utilizzare poll() su sistemi con grossi carichi.
Uhm, si, ho letto, ma non mi riferivo allo
specifico di quella implementazione, bensi`
alla semplice possibilita` di usare i thread
(in user space) ed un qualche (da definirsi)
meccanismo di sincronizzazione.
In particolare mi interesserebbe sapere il
possibile compromesso tra prestazioni e
flessibilita`.
Come dicevo in un altro thread, in user space
hai la possibilita` di controllare in maniera
piu` fine cosa interessa fare.
Ovviamente rischi un calo di prestazioni.
Il punto e`: quanto rischi e quanto guadagni?
bye
-- 
  Piergiorgio Sartor

 magari tornare indietro...
Che male c'è, nessun modello è Perfetto :)
-- 
Lorenzo

 Che male c'è, nessun modello è Perfetto :)
Uhm, ma il fatto che ognuno si muova nella
direzione dell'altro mi da da pensare che
non siano perfetti neanche in uno scopo
specifico, ammesso che sia stato definito.
Da qui la domanda su come trovare un compromesso
tra kernel space e user space.
bye,
-- 
  Piergiorgio Sartor

 residenza in cache... Questo per esempio.
Complessità come cambiamento radicale nei code path si,
codice più ingombrante no perchè la patch è/era circa 70kb.
L'eseguibile non ha aumenti apprezzabili nelle dimensioni.
-- 
Lorenzo

 L'eseguibile non ha aumenti apprezzabili nelle dimensioni.
Calma, calma, questo e` un discorso piu` generale,
dato che dal kernel 2.0 al 2.4, senza aggiungere
feature, mi ritrovo con un binario compresso che e`
il doppio.
Quindi, magari non questa patch in particolare, ma
tutto l'insieme di feature/patch/fix che ci sono
stati, hanno fatto raddoppiare il kernel.
Ovviamente la causa non e` di un singolo upgrade, ma
di tutto un insieme di pezzi e pezzettini che alla
fine fanno numero. Incluso il patch in questione.
Questo aumento di dimensioni si sente a livello di
cache, ovviamente...
Ma tu dirai che il problema si sentirebbe anche
avendo il codice in user space... Certo, ma in
questo caso e` accettabile, dato che sarebbe
comunque successo... ;-)
bye,
-- 
  Piergiorgio Sartor


E' vero, l'altro giorno ho fatto una prova: ho compilato il 2.4.19 per 386
lasciando solo lo stretto necessario delle periferiche (console vga, seriali,
tastiera standard, floppy, nessun controller scsi o ide, un solo file system
(minix), una scheda di rete ne2k), IPC e networking.
Risultato: piu' di 500 kilobyte di zImage, quasi il doppio della stessa cosa
con il 2.2.x. Mi viene il dubbio che ci sia rimasto qualcosa di troppo dentro.
Alessandro.

 comunque successo... ;-)
Guarda, un AIO in userspace ben fatto mi piacerebbe molto
di più di una implementazione nel kernel.
Del resto Linux è andato avanti per anni con questa soluzione
sfruttando il fatto che batte tutti gli Unix commerciali nei
microbenchmark come context switch e latenza di fork()/clone().
Non faccio salti di gioia nel vedere aio_read() e co. nel kernel..
-- 
Lorenzo

 Non faccio salti di gioia nel vedere aio_read() e co. nel kernel..
Non e` questione di gioia o meno, ma cercavo di
capire il senso di questa scelta vs. user space.
Da un lato mi si dice che NT e` buono perche` ha
l'I/O asincrono in user space, dall'altro mi pare
che non sia proprio una gran scelta, ma Linux lo
segue. Perche`?
bye,
-- 
  Piergiorgio Sartor

 segue. Perche`?
Spero di non scrivere cappellate, qui si va molto vicini al punto dove 
finisce la mia sapienza e comincia la mia ignoranza. :-)
L'i/o gestito in user mode, sia con linux che con nt, deve sottostare 
_rigidamente_ alle regole dello scheduler, cioè del multitasking 
preemptive.
Viceversa, in kernel mode, il grado di libertà è maggiore, tant'è che 
(almeno sotto nt) un driver scritto male può bloccare il sistema, ma al 
contempo un driver scritto bene lavora molto velocemente perchè ha il 
controllo delle risorse (potrebbe anche mascherare gli irq con una CLI).
Un caso eclatante mi capitava quando usavo la awe32 sotto nt (l'accozzaglia 
di codice prodotto da creative per la awe merita il titolo di principe dei 
drivers mongoli); essendo la mia vecchia awe equipaggiata di 32 mega di ram 
on board, all'avvio caricavo il mio bel soundfont da 28 mega, ed essendo la 
suddetta awe dotata di bus isa, i 28 mega di suoni transitavano (lentamente 
e comodamente) attraverso tale obbrobrio di bus.
Ebbene, questo sospendeva il caricamento di NT, che riprendeva furioso non 
appena la awe aveva finito di digerire il soundfont, e me ne accorgevo 
senza ombra di dubbio, perchè il disco fisico da cui caricavo il sf era 
diverso da quello da cui caricavo NT, me ne accorgevo dalle lucette.
Ecco, questo è un caso in cui mi sarebbe piaciuto che il driver della awe 
fosse stato scritto in user mode, ma è uno dei pochi casi, perchè con 
drivers fatti bene si guadagna eccome.
saluti cooperativi

 si evidenzia il limite di utilizzare poll() su sistemi con grossi carichi.
well, non ho letto il contenuto del link, ma se lavori
su BSD, puoi tranquillamente utilizzare kqueue per gli eventi.
E cmq, sempre sulla stessa man page di kqueue si trovano i 
riferimenti a cose come:
aio_read, aio_write, aio_error, etcetc
[flag@southcross flag]$ apropos aio
aio_cancel(2)            - cancel an outstanding asynchronous I/O operation (REALTIME)
aio_error(2)             - retrieve error status of asynchronous I/O operation (REALTIME)
aio_read(2)              - asynchronous read from a file (REALTIME)
aio_return(2)            - retrieve return status of asynchronous I/O operation (REALTIME)
aio_suspend(2)           - suspend until asynchronous I/O operations or timeout complete (REALTIME)
aio_waitcomplete(2)      - wait for the next completion of an aio request
aio_write(2)             - asynchronous write to a file (REALTIME)
[flag@southcross flag]$
Era questo che intendavate per async-i/o?
-- 
Paolo
Italian FreeBSD User Group: 
http://www.gufi.org

 drivers fatti bene si guadagna eccome.
Esatto, il fatto e` che in user mode, dovendo sottostare
allo scheduler, sei sicuro di far funzionare il resto del
sistema, mentre in kernel mode, ti serve un kernel preemtable.
Nota: ti _serve_.
Pero` se hai un uK, ti ritrovi con entrambe le cose agratis.
Allora, nella mia confusione, ancora mi chiedo chi
glielo fa fare, di avere questo mixing di user/kernel
space, apparentemente insensato.
bye,
-- 
  Piergiorgio Sartor

 space, apparentemente insensato.
A me non sembra insensato affatto, in user mode deve andare tutto quel 
codice che:
A) non richieda prestazioni particolari al sistema (problema della latenza 
ecc.).
B) non sia certificato per girare a livello privilegiato (cioè rischi di 
corrompere il resto del sistema).
Fatto salvo questo, ricordiamoci anche che il mt cooperative (del mac e poi 
di win 3.1) aveva anche dei vantaggi in termini di prestazioni; microsoft 
abbandonò il cooperative perchè la quantità di sw scritto coi piedi, fu ben 
presto tale da rendere impossibile quel tipo di approccio.
saluti cooperativi

 presto tale da rendere impossibile quel tipo di approccio.
:-)
bye,
-- 
  Piergiorgio Sartor

 segue. Perche`?
Perchè Linux è usato sempre di più in grandi ambienti
con grandi db etc etc, e le prestazioni in questo caso
sono critiche, lasciando in secondo piano questioni
teoriche di eleganza nel riusare primitive già presenti.
-- 
Lorenzo

 Credo che ti avanzi pure Gnome2 & il resto della fuffaglia colorata...
Ma come, tutta quella robaccia di proprieta' di Stallman su una ISO di 
FreeBSD? :PP
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it

 FreeBSD? :PP
Certo, infatti la GPL e' la licenza che ammazza il mercato e limita le alternative.

 alternative.
ROTFL :D

 teoriche di eleganza nel riusare primitive già presenti.
Quindi e` una questione prettamente "commerciale"?
bye,
-- 
  Piergiorgio Sartor

Pogoboy wrote:



.. e fermarsi 30 secondi (prima di premere il tasto Enter) a meditare
sulla cazzata che hai postato [1]? :-)
C:\>iao Angelo
[1] o in alternativa aggiungere uno smile a fine frase per farci capire
    che scherzavi quando ha fatto una simile afermazione
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

     che scherzavi quando ha fatto una simile afermazione
Illuso :D

 Infatti, molti SO RT usano _solo_ mt cooperative...
Dici? Mi pare strano.
saluti real time

 FreeBSD? :PP
E gira pure benino! Il porting di KDE non è completo, ma è molto fluido.
saluti disorientati

 sulla cazzata che hai postato [1]? :-)
Guarda Gnome e KDE e poi dimmi se non e' vero =)

 GPL.
Tu spiegami perche' la gente muore ancora di malaria =)

Pogoboy wrote:



Non credo di aver capito la risposta, scusami ma sono un po' stanco
(o sono un po' duro scegli l'alternativa che ti piace :-)).
In che senso KDE o Gnome limitano il mercato o limitano le scelte?
L'alternativa a Gnome e KDE e' avere l'interfaccia a carattere?
In quest'ultimo caso mi sembra che la scelta sia triplicata, o sbaglio :-)
C:\>iao Angelo


 Quindi e` una questione prettamente "commerciale"?
Credo sia una questione di seguire le esigenze degli utenti
perchè sono questi che in ultima istanza decretano il successo
o meno di un OS, altrimenti si fa la fine dei uk :)
Potrebbe esserci anche un altro motivo, più tecnico, e cioè
che lo standard POSIX per l'AIO abbia un pessimo design e
che l'unico modo per per avere una implementazione efficiente
sia un supporto del kernel, per quanto minimo.
Un pò come i POSIX threads.
-- 
Lorenzo

 Dici? Mi pare strano.
Perche`, come dicevo sopra, il mt cooperative
consente miglior controllo dei task switch e
quindi di tutto il sistema.
Ovviamente _tutto_ deve essere controllato da
chi fa l'applicazione, non si puo` aggiungere
SW di terze parti, senza sapere come si comporta.
bye,
-- 
piergiorgio

 che lo standard POSIX per l'AIO abbia un pessimo design
è tutto relativo. E' possibile che sia stato scelto quel design per 
pressioni da parte di vendor che avevano già implementato l'I/O come 
Microsoft, e non volevano perdita di prestazioni per un design che li 
avrebbe costretti ad usare un accrocchio che:
 - dipende da una particolare runtime C. Può non sembrare a chi è
   abituato a Linux, ma è una grossa sconfitta
 - dipende da una seconda libreria (POSIX thread è una libreria, le
   "vere" system call per il multithreading sono a discrezione
   dell'implementazione - Solaris ha un set di chiamate lwp_*, HP_UX
   thr_*, ecc. Ovviamente, anche qui per rispettare interfacce di
   multithreading preesistenti)
 - consuma risorse. Un thread può essere leggero quanto ti pare, ma
   almeno lo stack deve avercelo
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 asincrono (per esempio) in user space...
leggi il mio post piů su nel thread - in Windows NT tutto l'I/O č 
asincrono, per design, quindi non costa niente esporlo nelle system 
call. A implementarlo con un worker thread si sarebbe perso parecchio, 
un thread spreca risorse sia a livello di sistema (allocazione di un 
thread id e un TCB), sia a livello di processo (stack, TIB/TEB)
Piů o meno come la questione multithreading: se pensi lo scheduler sin 
dal principio come una roba che ordina uno heap di thread, anzichč di 
processi, tutto misteriosamente migliora, e tutto un sacco di cose che 
altrimenti ti sarebbero costate un notevole sforzo di astrazione 
funzionano senza che nemmeno te ne accorga


 di più di una implementazione nel kernel.
non so dove dirlo, quindi mi aggancio qui. In Windows NT non esiste 
alcuna differenza tra I/O sincrono e asincrono. Infatti, in realtà, 
tutto l'I/O è asincrono: si costruisce un pacchetto di richiesta e lo 
si accoda tra le richieste alla device del file. Quando chiedi di fare 
I/O sincrono, semplicemente la system call associa alla richiesta un 
evento che la device deve segnalare quando l'operazione è completa, e 
si mette in attesa che l'evento sia segnalato. Quando chiedi di fare 
I/O asincrono, semplicemente, la system call passa nella richiesta un 
evento specificato dal chiamante anzichè allocarne un altro, e lascia a 
te, chiamante, decidere quando e quanto aspettare per il completamento. 
Le system call di Windows NT non espongono i segnali mandatory ma solo 
quelli advisory (il thread deve controllare esplicitamente se ci sono 
segnali in coda), quindi niente segnali di completamento (SIGPOLL?). 
Sono possibili, ovviamente, associando alla richiesta una routine di 
completamento, e sollevando i segnali da questa routine - scrivendosi 
le proprie system call, beninteso. Spero di aver risposto ai dubbi del 
Sartor (rendetevi conto che m'avete fatto passare una serata e una 
mezza mattinata a leggere il DDK)


 prestazioni;
far artificialmente stravincere Photoshop per Mac nei benchmark?


 far artificialmente stravincere Photoshop per Mac nei benchmark?
Vero, ciň non toglie che un buon cooperative sia piů veloce.
Che ci vuoi fare, amo le utopie.
saluti utopici 

 sia un supporto del kernel, per quanto minimo.
Immagino che possa essere il caso.
In effetti questo ci riporta all'argomento iniziale,
cioe` il minimo set di primitive per fare qualcosa di
utile. Magari avere questo tipo di controllo a livello
kernel e` davvero necessario.
bye,
-- 
piergiorgio

 kernel e` davvero necessario.
Tu non fai i conti con gli standard :)
-- 
Lorenzo

 thread id e un TCB), sia a livello di processo (stack, TIB/TEB)
Su questo sono meno sicuro, dato che per l'AIO
devi comunque avere code & contesti separati.
bye,
-- 
piergiorgio

 Tu non fai i conti con gli standard :)
Infatti, secondo me, nello specifico, non si
dovrebbero proprio considerare.
In altri casi si, ma se un certo design X e`
efficiente, ma non standard, mi sta bene lo
stesso. Che siano gli applicativi ad essere
modificati, che tanto il porting si deve
comunque fare lo stesso.
bye,
-- 
piergiorgio

Doc, voglio essere uno degli articolisti :-)
facciamoci anche un sito dai :-)
NotizieInformaticheInventate.org

 NotizieInformaticheInventate.org
Si, e poi ci vuole quello che ci bada... :-|
saluti incasinati

 comunque fare lo stesso.
Il problema è che gli applicativi costituiscono una
montagna si sw dotata di una inerzia enorme.
Tuttavia credo che storicamente questa resistenza alla
modifica degli applicativi derivi dall'uso di sw proprietario
senza sorgenti e senza terze parti che lo potessero modificare.
Generalmente nel mondo open source le cose hanno una inerzia
minore e vorrei tanto che si seguisse questo pensiero.
-- 
Lorenzo

 code & contesti separati.
non ho capito. Di cosa stai parlando, esattamente?


 non ho capito. Di cosa stai parlando, esattamente?
L'AIO, per essere realizzato, deve sempre contare su due
elementi, uno che richiede l'AIO, l'altro (asincrono) che
aspetta l'irq (o quello che) mentre il primo continua.
Comunque realizzi 'sta cosa, sempre due "stati" (cioe` due
contesti) devono essere mantenuti, devi (tipicamente) usare
code di comunicazione, segnali vari, etc.
La differenza potrebbe essere che in kernel space la cosa
puo` essere ottimizzata e ridotta ai minimi termini, ma
sempre contex switch devono occorrere, dato che "stati"
diversi devono essere mantenuti, cosi` come nel multithreading.
bye,
-- 
  Piergiorgio Sartor

    almeno lo stack deve avercelo
Anche il kernel ha un suo stack, piu` "multi-roba"
ci metti, piu` grande deve essere lo stack.
bye,
-- 
  Piergiorgio Sartor

 minore e vorrei tanto che si seguisse questo pensiero.
In realta` un buon layer di librerie standard
dovrebbe coprire molto, se non tutto.
Quindi basterebbe "toccare" solo quel layer, il
che e` sicuramente meno che non cambiare tonnellate
di software.
D'altronde, spesso, il software accede direttamente
a device level, quindi un cambio diventa drammatico
(vedi l'interfaccia SCSI qualche kernel fa...).
bye,
-- 
  Piergiorgio Sartor

 (vedi l'interfaccia SCSI qualche kernel fa...).
Stai dicendo di una applicazione che accedeva ai device SCSI
attraverso i comandi del protocollo stesso scavalcando il
sistema operativo?
-- 
Lorenzo

 ci metti, piu` grande deve essere lo stack.
Lo stack del kernel č fisso a 2 pagine, 8kb su x86.
Se la "multi-roba" ne usa di piů, la si corregge per
rientrare nel limite.
-- 
Lorenzo

 rientrare nel limite.
Magari non e` possibile... :-)
bye,
-- 
  Piergiorgio Sartor

 sistema operativo?
cdrecord...
Deve accedere a basso livello all'interfaccia,
usando SCSI generic.
bye,
-- 
  Piergiorgio Sartor

 Magari non e` possibile... :-)
Perchč?  Puoi sempre usare kmalloc().
Ah, ovviamente le funzioni ricorsive sono vietate ma
č sempre possibile scrivere una funzione non ricorsiva :)
-- 
Lorenzo

 usando SCSI generic.
Sarebbe bello fare "cp myiso.iso /dev/hdX" ma temo che
la masterizzazione di un CD non sia una semplice copia
di un'immagine iso, c'è un sacco di roba da scrivere
prima e dopo l'immagine.
Inoltre ci sono parametri come -speed, -audio, -data etc.
-- 
Lorenzo

 è sempre possibile scrivere una funzione non ricorsiva :)
Non _esplicitamente_ ricorsiva... :-)
bye,
-- 
  Piergiorgio Sartor

 Inoltre ci sono parametri come -speed, -audio, -data etc.
Esatto, quello e` il problema principale.
BTW, la nuova interfaccia per 1394 (dv1394) sembra
seguire questo principio.
Secondo l'autore basta dare un:
cat /dev/dv1394 >pippo.dv
per avere il file sull'HD in formato raw DV.
Non  male...
bye,
-- 
  Piergiorgio Sartor

 Non _esplicitamente_ ricorsiva... :-)
Idem :)
-- 
Lorenzo

 Non  male...
Non male davvero.
-- 
Lorenzo

 Bisognerebbe misurare, non c'è altro modo di saperlo con precisione.
Ovviamente e non e` neanche facile, ma richiede
parecchio lavoro.
bye,
-- 
  Piergiorgio Sartor

 comunicazione, segnali vari, etc.
mi hai messo la curiosita' addosso. Adesso devo vedere come funziona la 
spedizione delle richieste di I/O


 Magari non e` possibile... :-)
Windows NT gira con 12 KB di stack per il kernel mode da 9 anni :-)


 spedizione delle richieste di I/O
Ottimo, poi ci racconti i dettagli.
bye,
-- 
piergiorgio

 Windows NT gira con 12 KB di stack per il kernel mode da 9 anni :-)
In generale, magari non e` possibile,
e poi c'e` sempre in discorso delle
allocazioni segrete.
Se hai una coda di messaggi, hai allocato
dei buffer che possono essere visti come
estensioni dello stack... Per esempio...
bye,
-- 
piergiorgio

 In generale, magari non e` possibile,
Tanto riporta appena installato, anche col sp6a. Gonfia mostruosamente 
installando IE.
saluti minimali

 Ottimo, poi ci racconti i dettagli.
quando avrò tempo e voglia, s'intende :-P


 naaah, si fa solo al boot una schifezza del genere. Non andrebbe fatta, 
Pensavo a qualcosa di inverso.
Cioe` un FS in kernel che gestisce i file +
tabelle di attributi, senza un significato
(per lui). Gestisce metafile.
Poi il FS user space pensa a riempire opportunamente
le tabelle ed il resto...
bye,
-- 
piergiorgio

 Certo, infatti la GPL e' la licenza che ammazza il mercato e limita le alternative.
ROTFL :D



Chiedo scusa, vecchio messaggio ripartito per sbaglio
See you,
		Silver Drake
 
«Ti sentivo ruttare e ho pensato che fossi già al lavoro»
(mia moglie, 20-01-2003)