From owner-freebsd-hackers Wed Apr 5 11:45:53 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA25188 for hackers-outgoing; Wed, 5 Apr 1995 11:45:53 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA25182 for ; Wed, 5 Apr 1995 11:45:52 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00795; Wed, 5 Apr 95 12:39:03 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504051839.AA00795@cs.weber.edu> Subject: Re: Suggestion on slow probing devices To: bde@zeta.org.au (Bruce Evans) Date: Wed, 5 Apr 95 12:39:03 MDT Cc: peter@bonkers.taronga.com, phk@ref.tfs.com, freebsd-hackers@freefall.cdrom.com, uhclem@nemesis.lonestar.org In-Reply-To: <199504051738.DAA26590@godzilla.zeta.org.au> from "Bruce Evans" at Apr 6, 95 03:38:48 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > >I'd say the right thing to do would be to get the timer flying and make > >a "HW-probe-attach" process... > > lkm'ed drivers will make this both easier and harder. Easier because they > will have an process context to sleep on so they won't need to call DELAY() > for long delays. Harder because they must leave the device in a safe state > before sleeping and because they must not call DELAY() for delays longer > than are acceptable in normal operation (perhaps 100usec max). Yay, kernel high resoloution timers and one-shots! Yay, kernel preemption and multithreading! Boo, work involved! Free Rah, Rah, Rah! Bee Rah, Rah, Rah! Ess Rah, Rah, Rah! Dee Rah, Rah, Rah! Free Bee Ess Dee Probe, Probe Probe! Yay, team! Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.