Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Oct 2000 00:53:15 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        gcorcoran@lucent.com (Gary T. Corcoran)
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject:   Re: Module parameters?  (WildWire DSL card driver)
Message-ID:  <200010170053.RAA04059@usr05.primenet.com>
In-Reply-To: <39E7AB10.EADBB53B@lucent.com> from "Gary T. Corcoran" at Oct 13, 2000 08:38:40 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> Back in July I was asking about the capability to set parameters (variables)
> when loading my DSL driver module.  There was a small flurry of activity
> about some initial ideas on how to do it, but I never heard any more about
> it.  Did you (Mike, Warner, or anybody) have time to work on it?  Did this
> capability get put into release 4.1, by any chance?  :)

A common trick "in the old days" was to load a parameter module
that the driver module depended up, and give it a hook that it
could call to get data from the parameter module, by reference
to a statis structure.

You would send the data down to the parameter module before you
load the driver module; thus:

1)	Load paramter module
2)	Open parameter module psuedo device
3)	Ioctl parameters up/down via the pseudo device
4)	Load the deriver module
5)	Driver module attach routine call parameter_fetch()
	routine out of parameter module
6)	Parameter module returns static parameter structure,
	by reference
7)	Driver dereferences parameters out of static struct
8)	Driver completes attach

Really, it seems to me that if this driver looks like an
ethernet interface, you should be able to set the parameters
after the atttach, before bringing the interface up.

Alternately, if the problem is lack of reference counting on
FreeBSD's part, and you therefore can't do the job on the
open, since you can't track closes aws they happen, only the
last clse, there are a couple of approaches:

A)	Have one driver, but two devices; one for control,
	and one for data

B)	Have only one device, but inactivate it until a
	special ioctl() starting it up is issued; thus:

	1)	Open
	2)	Set parameters
	3)	ioctl(fd,LUCENT_START,...)
	4)	...
	5)	ioctl(fd,LUCENT_STOP,...)
	6)	Set new parameters
	7)	ioctl(fd,LUCENT_START,...)
	8)	...

One of these aprroaches should be able to work for you; the parameter
driver approach with a pseudo device will definitely work, but is
much less elegant (parameters on an attach probably mean that you
are doing something in an attach that really belongs elsewhere).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010170053.RAA04059>