Date: Mon, 28 Jul 1997 17:36:58 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, nate@mt.sri.com, hosokawa@jp.freebsd.org, current@FreeBSD.ORG Subject: Re: pccard and -current; a long way to go. :-( Message-ID: <199707280806.RAA05543@genesis.atrad.adelaide.edu.au> In-Reply-To: <25979.869936845@time.cdrom.com> from "Jordan K. Hubbard" at "Jul 26, 97 10:07:25 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying: > > Because the current startup code is _too_stupid_ to deal with > > transient interfaces. This was hashed out ages ago. > > > > If we accept your model where the system can't start until a network > > card is inserted to match the ifconfig_foo lines, I'd be screwed if I > > decided to boot without my 'net card to save power. > > Well, then we have a problem which really needs resolution since it's > not going to work well the way it is with the current installation > code. Understood. > I've also no objection to changing things so that, somehow, a pccard > device is somehow recognised and the behavior of adding ifconfig_foo > lines is skipped in favor of adding more specialized configuration, > but I think that we need to seriously think about our configuration > mechanisms and how "dynamism" in your device picture is going to be > handled. For a device which may enter and leave the picture at any > time, you obviously may wish to treat its configuration data > differently. The question is: How exactly? :) I think that a clear separation has to be made between the configuration information and the possible process(es) that may use this information. The rc.conf idea helps this immensely. My "vision" for looks something like this : - configuration information is kept "somewhere" (rc.conf for now) - The parameters include a list of interface names to be looked for, and corresponding address/routing parameters associated with these interfaces. - a script exists which, given an interface name, consumes the parameters for said interface and configures/deconfigures it. - at startup, the list of configured-for interfaces is scanned, and any such interfaces present are configured using the script above. ie. at bootup, fixed interfaces have effectively "arrived". - upon PCCARD arrival/departure, the card's identifier is linked to a driver name (as is currently done). The PCCARD arrival/departure handler can then use the same script as above to manage arrival and departure, using the same parameters as for fixed interfaces. - one could go one further and specify type-like wildcards for interface congfiguration, eg. "ether", so that arrival of _any_ ethernet card would result in it being configured without having to stipulate the exact driver. Yah, I know I should just get out and do it. Gimme something with PCCARDS in it that I can call "mine" 8) 8) 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707280806.RAA05543>