SLT ( Săptămâna de lucru la TFM ) Partea 2

Saptamina care tocmai a trecut se poate numi saptamina re-impachetarilor. Foarte multe pachete au trecut prin procesul de reimpachetare. De ce ?

TFM2 avea in installer notiunea de template. Si am pus noi in tfm citeva profile care se mulau destul de bine la momentul respectiv pe nevoi. Numai ca nimeni nu a mai updatat acele profile de atunci. Intre timp pachetele au alte denumiri , majoritatea instalarilor s-au facut full si nu s-a tinut seama ca mai exista profile si mai mult ca profilele nu mai merg. Pina saptamina asta cind am incercat sa fac un sistem minimal pentru un mail exchanger care sa ruleze via uml.

Saptatul la UML a fost o a doua directie de sapaturi saptamina asta. Dar despre uml vorbim in SLT de saptamina viitoare

Prin metoda while ( fail ) do { fail = try() } am string intr-un director pachetele care mi se parea mie ca sint necesare pentru qmail si am incercat sa le instalez intr-o imagine montata in loop.

Metoda de instalare cu un fisier montat in loop este mult mai rapida decit sa instalatul intr-un director normal. De ce ? Pentru ca la o a doua instalare va trebui sa stergeti continutul directorului si umount / mkfs.ext3 / mount merge infinit mai repede decit rm -rf

Dupa ce am reusit sa string pachetele care depind unele de altele ( operatiunea micul chinez pe plantatie ) studiind rezultatul am constat ca o gramada de spatiu se pierdea cu documentatii, manuale si altele. Am hotarit sa refac rpm-urile care contineau documentatii si sa le mut in subpackete de sine statatoare. singurul “drawback” al actiunii ar fi ca sint mai multe pachete in tfm. Multe dar mai mici.

Si de aici toata distractia cu reimpachetatul. perl , cpio , udev , module-init-tools , pam sint doar citeva din ele. Operatiunea de reimpachetare va mai dura o perioada de vreme urmind a fi finalizata in tfm 3.1 probabil. In alte pachete executabilele aveau informatiile de debug asa ca au necesitat strip.

Si pentru ca mi-am adus aminte ca nu am avut timp sa povestesc aventurile cu kernelul si pptp o sa o fac in continuare.

A trebuit testat integrarea pptp in ADS. Moment in care au aparut problemele.
Serverul se manifesta ciudat. Este prima data cind vad erori de genul asta in linux. Pentru ceva timp am avut senzatia ca in loc de server linux e un windows instalat prost. Iara cum se manifesta:

What happens is that when pptp reads from the pty, we call
read_chan() in drivers/char/n_tty.c on the master side of
the pty. That copies all the characters out of its buffer
to userspace and then calls check_unthrottle(), which
calls the pty unthrottle routine, which calls tty_wakeup
on the slave side, which calls ppp_asynctty_wakeup,
which calls tasklet_schedule. So far so good. Since we are
in process context, the tasklet runs immediately and calls
ppp_async_process(), which calls ppp_async_push, which calls
the tty->driver->write function to send some more output.

However, tty->driver->write() returns zero, because the master
tty->receive_room is still zero. We haven't returned from
check_unthrottle() yet, and read_chan() only updates
tty->receive_room_after_ calling check_unthrottle. That means
that the driver->writecall in ppp_async_process() returns 0.
That would be fine if we were going to get a subsequent
wakeup call, but we aren't (we just had it, and the buffer
is now empty).