From owner-freebsd-current Sun Sep 26 11:48:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles530.castles.com [208.214.165.94]) by hub.freebsd.org (Postfix) with ESMTP id 96AF415293 for ; Sun, 26 Sep 1999 11:48:28 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id LAA13232; Sun, 26 Sep 1999 11:41:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199909261841.LAA13232@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dmaddox@conterra.com Cc: current@FreeBSD.ORG Subject: Re: Loss of Functionality with newpnp In-reply-to: Your message of "Sun, 26 Sep 1999 14:15:29 EDT." <19990926141529.A1143@dmaddox.conterra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Sep 1999 11:41:14 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, Sep 26, 1999 at 10:51:59AM -0700, Mike Smith wrote: > > > Sigh. Again, I didn't demand anything. > > > > > > I simply pointed out that functionality had been lost. If I > > > was the author of this code, I would *want* feedback on how > > > it was working out for people out here in userland. I assume > > > that the authors in question _do_ want such feedback. > > > > Actually, in your case, no. The "functionality" you're claiming was > > lost was actually an unintentional side-effect of the code which will > > intentionally not be emulated. > > I'm not sure I follow you here. My card was recognized and configured > properly by the old PnP code. It is not recognized and configured > properly by the new PnP code. How can that be classified as simply > 'an unintentional side-effect of the code'? PnP is an infrastructure facility used by drivers to detect and configure hardware. The side-effect you were relying on was that the old code would indiscriminately configure any and all PnP hardware regardless of whether a driver had requested it to. > It seems to me that PnP functionality should not be dependant on any > particular driver... I mean, the PnP code and the audio code (and the > network driver code, and any other possible PnP device driver code) > are seperate things, no? No. > Shouldn't it be the job of the PnP code to > recognize and configure the device so that it probes and attaches, > regardless of what driver finds it? No. > At least, it appears to me that > that is what the old PnP code did. My card worked just fine with it, > regardless of whether I selected 'pcm' or 'snd' in my kernel config. I don't think an explanation of how PnP works or how it fits into our device architecture is feasible at this point, so I'm going to encourage you to do some research of your own. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message