From owner-freebsd-current Wed Jan 17 19: 8: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 14A6437B400; Wed, 17 Jan 2001 19:07:39 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 1CF5728811; Thu, 18 Jan 2001 09:07:32 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 0D76328804; Thu, 18 Jan 2001 09:07:32 +0600 (ALMT) Date: Thu, 18 Jan 2001 09:07:31 +0600 (ALMT) From: Boris Popov To: Alfred Perlstein Cc: arch@freebsd.org, current@freebsd.org Subject: Re: HEADS-UP: await/asleep removal imminent In-Reply-To: <20010117031618.K7240@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Jan 2001, Alfred Perlstein wrote: > I have a patch here that removes await/asleep from the kernel API. > > http://people.freebsd.org/~alfred/noasleep.diff > > Matt Dillon implemented alseep/await quite some time ago and the > only thing that's using it is ata. In order to clean up some of > the schduler and vm system I'm removing support for it. Hmm, I've found this API usable for synchronization between two kernel threads/processes: alseep(&somewhere); wakeup(&anotherprocess); await(&somewhere); where 'anotherprocess' do some job and call wakeup(&somewhere). I suspect that this can be emulated with mutexes and/or conditional variables. So, it is possible to keep the API, but change its implementation to allow mentioned cleanup of scheduler ? P.S. it is already too hard to maintain external kernel modules even within various releng_4s, not to mention -current and releng_3... -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message