Télécom PRO tout en un : 29 Euros
Title: IC telecom Si ce message ne s'affiche pas correctement, visualisez la version en ligne La rduction des cots gnraux est un enjeu crucial pour la comptitivit de votre entreprise. Avec plus de 10 ans d'exprience dans les tlcommunications, ICtelecom spcialiste de la voix sur IP, est l'inventeur du guichet unique pour les entreprises. Fort de sa matrise des technologies en tlcommunications et des rseaux IP et bnficiant dune position sans concurrence de premier plan sur le march de la convergence (tlphonie fixe, tlphonie mobile, internet), ICtelecom dveloppe pour le march professionel des offres triple play packages (voix, data, mobile). ICtelecom fournit plus de 12000 utilisateurs travers plus de 2000 sites installs. SOYEZ DANS LES 50 PREMIERS* souscrire l'offre ICtelecom et recevez GRATUITEMENT ce camscope sanyo *Offre soumise conditions, valable pour toutesouscription jusqu'au 31 dcembre 2009 inclus, partir de 3 lignes tlphoniques sous rserve d'acceptation du dossier par ICtelecom. Remplissez ce formulaire pour ne plus recevoir notre newsletter. A rception, celui-ci sera pris en compte conformment la loi n 78-17 du 06-01-1978 relative linformatique, aux fichiers et aux liberts modifie par la loi n2004-801 du 06-08-2004
Re: [PATCH 0/1] Was: utrace-cleanup branch
3. Now that we have utrace-resume, can't we kill report-resume_action ? I thought this initially when making the change and then decided against it. I don't recall exactly what was in my mind at the time. It would take some more thought now to be sure whether there is a semantic problem. But at any rate, keeping it reduces the number of cases in which we take the utrace lock in finish_callback_report, which seems like a good thing. Still, if you propose a patch to remove it with thorough rationale on why it's good or better, then that will be fine. Thanks, Roland
Re: [PATCH 128] introduce suppress_sigtrap() to prevent unwanted send_sigtrap()
In this case the tracee resumes and stops after syscall_trace_leave() to report PTRACE_EVENT_FORK, but since it passes syscall_trace_leave() with TIF_SINGLESTEP set the tracee gets the unwanted send_sigtrap(). Note: of course, this is hack. I think this should be move to utrace layer. Unless we are going to call finish_resume_report(), finish_report() should look at report-action and clear TIF_SINGLESTEP when needed. I thought we had just covered this before. TIF_SINGLESTEP is an arch implementation detail and will never belong in either the ptrace layer or the utrace layer. All of this is just to work around the x86-specific case of the step state on return from tracehook_report_syscall_exit() producing (or not producing) the synthetic single-step SIGTRAP. I think the sequence of changes we'll want for this is something like: 1. (upstream) add arch hook(s) for single-step SIGTRAP siginfo_t + arch fields (i.e. x86's thread.error_code + thread.trap_no). 2. (upstream) change tracehook_report_syscall_exit() to use force_sig_info instead of ptrace_notify, use that arch hook - powerpc et al PTRACE_SINGLESTEP-over-syscall goes from ptrace-swallows-signal to normal signal case 3. (upstream) implement that arch hook for at least powerpc - synthetic SIGTRAP gets si_* as a real step would, rather than 0 4. (upstream) implement that arch hook for x86 5. (upstream) change x86 syscall_trace_leave to pass flag tracehook_report_syscall_exit(), not call send_sigtrap() - x86 PTRACE_SINGLESTEP from syscall-exit stop no longer fake-traps without another insn, but takes a true step trap after next insn - compatible with powerpc et al behavior, makes more sense 6. profit - more consistent behavior upstream, simpler mandate for utrace-ptrace Is there anything wrong with that? Thanks, Roland
