[lkml]   [2003]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [patch] printk subsystems

    > From: Karim Yaghmour []
    > I beg to differ. There's a point where we've got to stop saying "oh,
    > this buffering mechanism is special and it requires its own code."
    > relayfs is there to provide a unified light-weight mechanism for
    > transfering large amounts of data from the kernel to user space.

    But you don't need to provide buffers, because normally the data
    is already in the kernel, so why need to copy it to another buffer
    for delivery?

    That's the point I tried to address with the kue patches I posted
    last week - once you have the data, wherever, you just queue it
    for delivery, and provide the delivery subsystem for means to
    destroy it when it is delivered (and thus, not needed anymore)
    [currently I only support kfree(), but I plan to add a destructor
    function that at the same time can work as a callback for delivery].

    This is where I think relayfs is doing too much, and that is the
    reason why I implemented the kue stuff. It is very lightweight
    and does almost the same [of course, it is not bidirectional, but
    still nobody asked for that].


    Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
    (and my fault)
    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-03-22 13:34    [W:0.025 / U:9.556 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site