From owner-freebsd-hackers Tue Sep 16 01:07:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA05411 for hackers-outgoing; Tue, 16 Sep 1997 01:07:09 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA05376 for ; Tue, 16 Sep 1997 01:07:02 -0700 (PDT) Received: (qmail 11160 invoked by uid 1000); 16 Sep 1997 08:06:56 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 16 Sep 1997 01:06:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Julian Elischer Subject: Re: Fast Encryption (in kernel) seeked Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Julian Elischer; On 16-Sep-97 you wrote: > To answer this question correctly, > We need to know more details.. Gladly :-) > every algorythm has its day. It depends on what the situation is. > > For example, if there will be less than 100 of these 'pointers' > outstanding at a time, different schemes would be used to the case where > there are 100000 outstanding.. Oh, somewhere in between. A busy system may hold about 10,000 outstanding tickets. > can you guarentee that each pointer given out will be 'returned'? Not at all. I can guarantee that until it is returned, the pointer will be dormant. > will it be returned only once? Yup. > what if a process dies while owning a pointer? Then eventually the pointer goes away. > when does the buffer become free? very soon after the pointer comes back home. > who allocates the buffers? malloc. > I have code that does all this but it's only useful to you if > what you want to do matches the goals of what I was designing for.. > > tell me more.. This is part of the DLM. When a remote request comes in, we allocate a bucket (structure) to hold the remote request, send it up to a userspace daemon. The daemon resolves the target where the lock should be applied, sends a packet to that host, gets the result and puts is back to the kernel. The kernel gets the bucket, extracts from it the pointer, identifies who is sleeping, waiting for the request to be resoved, wakes it out. The process that slept wakes up and continues processing. Two points: a. This is a very inaccurate description of the remote leg in a shared lock processing. It is accurate enough to give you the background, though. b. I do NOT want this brief to be construed as a presentation of or introduction to the DLM. This will come soon enough. I want to guarantee that the cookie the kernel requestor sleeps on is unique within the kernel address space and genuine. To do so, I need to: a. Validate that it is genuine. b. Find, QUICKLY, the original bucket that holds the request; this is where the request and all its atndant pieces are. --- Sincerely Yours, (Sent on 16-Sep-97, 00:53:14 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313