[lkml]   [2005]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH 00/13] Introduce task_pid api

    > >>@@ -2925,7 +2925,7 @@ void submit_bio(int rw, struct bio *bio)
    > >> if (unlikely(block_dump)) {
    > >> char b[BDEVNAME_SIZE];
    > >> printk(KERN_DEBUG "%s(%d): %s block %Lu on %s\n",
    > >>- current->comm, current->pid,
    > >>+ current->comm, task_pid(current),
    > >> (rw & WRITE) ? "WRITE" : "READ",
    > >> (unsigned long long)bio->bi_sector,
    > >> bdevname(bio->bi_bdev,b));
    > >
    > >...and now printk is close to useless, because uer can't know to
    > >which pidspace that pid belongs. Oops.
    > Uhh, this patch doesn't introduce any kind of virtualization yet.
    > When that happens, _this_ code will remain the same (it wants the
    > real pid), but *other* code will switch to use task_vpid(current)
    > instead. This is an extremely literal translation of current->pid to
    > task_pid(current), both of which do exactly the same thing.

    Hmm... it is hard to judge a patch without context. Anyway, can't we
    get process snasphot/resume without virtualizing pids? Could we switch
    to 128-bits so that pids are never reused or something like that?

    Thanks, Sharp!
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-16 21:38    [W:0.020 / U:36.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site