From owner-freebsd-hackers Sat Apr 15 0:16:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id 194C737B708 for ; Sat, 15 Apr 2000 00:16:33 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id AAA30883; Sat, 15 Apr 2000 00:16:31 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Sat, 15 Apr 2000 00:16:31 -0700 (PDT) From: Doug White To: "Gary T. Corcoran" Cc: FreeBSD Hackers Subject: Re: Setting device options In-Reply-To: <38F63C11.860C901B@lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Apr 2000, Gary T. Corcoran wrote: > So, I want to know how I can "automagically" set the device options, > every time a user kldload's the device driver. > To give you a little background, here's how it works on the other > operating systems, and thus this is the type of thing I'm looking > for in FreeBSD. I'm not sure this is the model you want. In general, kld's get loaded once and stay there, usually at boot time. I would find it easier (and orthogonal with existing practice) to have a xxcontrol program (like siocontrol & friends) that parses a config file or command line options or what have you and passes them via an ioctl() to the driver. This reduces the startup complexity of your driver, and simple drivers are Good(tm). If you make your code available, there will be people who will want to statically compile the driver in, and you don't have a load event to pull arguments from in that instance. (I'm thinking of PicoBSD as an environment that doesn't bundle kernel modules.) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message