Re: An alternative way of populating /proc

From: Peter Stuge (stuge@cdy.org)
Date: Fri Apr 14 2000 - 19:08:35 EST

Next message: ying@almaden.ibm.com: "Re: umount2"
Previous message: David Ford: "Re: [patch] repost of netfilter/NIPQUAD patches"
In reply to: almesber@lrc.di.epfl.ch: "Re: An alternative way of populating /proc"
Next in thread: Borislav Deianov: "Re: An alternative way of populating /proc"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Fri, 14 Apr 2000 almesber@lrc.di.epfl.ch wrote:

>I see five possible approaches:
[..]
> - locking: a request can acquire a lock while working on the variables
[..]
>to avoid the most obvious DoS problems, locking would probably need a way
>to "chain" reads, such that the kernel never has to wait for user space
>to release a lock.

* Locked callback from kernel
* read() that stores all requested data in one call, thus lockable

The latter would of course demand enough storage allocated.

Dunno, right now I'm really REALLY tired, I probably shouldn't have posted
this at all. X-)

//Peter

-- irc: CareBear\ tel: +46-40-914420 irl: Peter Stuge gsm: +46-705-783805

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/

Next message: ying@almaden.ibm.com: "Re: umount2"
Previous message: David Ford: "Re: [patch] repost of netfilter/NIPQUAD patches"
In reply to: almesber@lrc.di.epfl.ch: "Re: An alternative way of populating /proc"
Next in thread: Borislav Deianov: "Re: An alternative way of populating /proc"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:25 EST