From owner-freebsd-hackers Thu Mar 30 13: 9: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ludwig.troikanetworks.com (host03.troikanetworks.com [12.31.172.3]) by hub.freebsd.org (Postfix) with ESMTP id 4AD8037BDF2; Thu, 30 Mar 2000 13:09:00 -0800 (PST) (envelope-from ericp@troikanetworks.com) Received: by host03.troikanetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Mar 2000 13:09:13 -0800 Message-ID: From: Eric Peterson To: 'Samuel Tardieu' Cc: "'hackers@freebsd.org'" , 'Mike Smith' Subject: RE: Deferred procedure call available? Date: Thu, 30 Mar 2000 13:09:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- Samuel Tardieu [mailto:sam@inf.enst.fr] writes: > Sent: Thursday, March 30, 2000 11:46 AM > To: Eric Peterson > Cc: 'hackers@freebsd.org' > Subject: Re: Deferred procedure call available? > > > >>>>> "Eric" == Eric Peterson writes: > > Eric> Sometimes called "task queues" or "deferred callbacks", they > Eric> allow an interrupt handler to schedule a (possibly predefined) > Eric> function to be called outside the context of the interrupt. > > (not an answer, just a suggestion) Is there anything you cannot do > with a userland program, that will be resumed by the interrupt > handler? Doing this even gives you the possibility of choosing the > priority of the deferred handler relative to other handler and regular > processes (as eCos does). Sam, Thanks for the response. With regard to your suggestion (my ignorance of FreeBSD drivers certainly shows through here, but...): 1. I'm porting an existing driver, so am trying to keep its basic structure intact. I don't believe that a user-mode entity has access to the memory/device address space I need to get to. 2. I suspect that going from kernel to (even high priority) user mode entails a non-trivial performance penalty (somebody please correct me if not!) One other approach I was thinking about was to have a sleeping kernel thread that I could wakeup when I needed to schedule a function to be called. I'm going to try out the timeout(9) routine that Mike Smith suggested, looks like just the ticket (thanks again, Mike). Regards, Eric -- Eric Peterson WB6PYK ericp@troikanetworks.com PGP: http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x4DA8EEF1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message