From owner-freebsd-hackers Tue Jan 27 13:30:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16649 for hackers-outgoing; Tue, 27 Jan 1998 13:30:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bootp.sls.usu.edu (bootp.sls.usu.edu [129.123.15.47]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16534 for ; Tue, 27 Jan 1998 13:30:15 -0800 (PST) (envelope-from kurto@bootp.sls.usu.edu) Received: (from kurto@localhost) by bootp.sls.usu.edu (8.8.2/8.8.2) id OAA19113; Tue, 27 Jan 1998 14:18:13 -0700 (MST) Date: Tue, 27 Jan 1998 14:18:13 -0700 (MST) From: Kurt Olsen Message-Id: <199801272118.OAA19113@bootp.sls.usu.edu> To: kurto@bootp.sls.usu.edu, luigi@labinfo.iet.unipi.it Subject: Re: Proposed PNP changes Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk >This is ok, but be sure not to overwrite the kernel table with the >info from the previous config. In particular for those entries with the >"os" flag set. Initially I'll probably use a different structure to store the config information. Mostly so that I can check for allowable values in userconfig. Plus I want to be as paranoid as possible so that I break as little as possible. >you are suggesting two things I believe: one is to do more than what >our PnP does now, i.e. recognize compatible tags; this requires to run >a little bit more of the pnp protocol, much like pnpinfo does. It adds >a little bit of complexity to the code though. Yes. But that's OK. >The other one is to make additional drivers PnP aware. jmg already >did this for sio, and this is not hard at all. I'm not so sure about this one. Unless we get into the pnp concept wholesale and allow dynamic changes of resources, I don't see that it's overly necessary for the device driver to know if a device (eg. my ethernet card) is plug and play or not. I am assuming that I'll be able to configure the card and then just let the normal ed driver handle it. In cases where we can read and interpret the compatiblility tag in a meaningful manner I think it would make more sense to use that than to add driver support for specific device/vendor names. >just lazyness on my side, because function pnp_isolation_protocol() >currently does both the insolation protocol and calls the config >afterwards. It should not be hard to split this into two pieces and >call one before userconfig, and the other one when configuring PnP >devices. Good, I was just a little concerned that perhaps the machine isn't in a state where we could do the isolation/cdn assignments. >Just make sure that the insolation gets called even when >userconfig is not used. Certainly. Even if we don't go to userconfig it will be nice to be able to print out the config information for pnp devices during the probe messages. My real motivation for doing this is that I recently purchased an Opti 925/CS4231A soundcard which has about 5 ldns but I don't know which ldn is which device. (ide controller, joystick, sb & mss and something else which has slipped my mind.) >And thanks a lot for volunteering to clean up this code! Thanks to you and Sujal for getting this going in the first place!