From owner-freebsd-mobile Tue Apr 30 14:38:27 2002 Delivered-To: freebsd-mobile@freebsd.org Received: from jupiter.linuxengine.net (jupiter.linuxengine.net [209.61.188.254]) by hub.freebsd.org (Postfix) with ESMTP id E199437B41C for ; Tue, 30 Apr 2002 14:38:14 -0700 (PDT) Received: from jupiterweb.commercevault.com (jupiterweb.commercevault.com [209.61.179.16] (may be forged)) by jupiter.linuxengine.net (8.11.6/8.11.0) with ESMTP id g3ULcEY03996 for ; Tue, 30 Apr 2002 16:38:14 -0500 Date: Tue, 30 Apr 2002 16:38:14 -0500 (CDT) From: John Utz X-X-Sender: john@jupiter.linuxengine.net To: freebsd-mobile@freebsd.org Subject: is there a technical reason for apm or pnp to NOT be klds? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi; i might resend this to -arch, but i'll start here :-) i dont think i'll bother with -hardware because that seems to be a black hole... The Story So Far: i've been looking at the tanimura newmidi code most intently lately. strange as this may seem, that lead me to: 1. look at pnpinfo, 2. discover that it appears to be *broken*; it always sez that it cant find any pnp devices even tho the compiled in 'options PNPBIOS' code finds plenty. this code finds and boots the ESS ISA AudioEngine OEM chip without fail. 3. decide that fixing pnpinfo a. is virtuous :-) b. moves forward my midi agenda by hopefully allowing the removal of some device detection code that is in the newmidi stuff. 4. conclude that the pnp code /usr/src/sys/isa/{pnp,pnpparse}.c should be reimplemented as a KLD. 5. decide to find another good example to work from 6. pick apm as a good example because it behaves in a way that i'd like to see pnpinfo behave... 7. discover that apm isnt a KLD either. :-( 8. wonder why apm isnt a KLD... 9. decide to ask list. so...'sup with that? is the only reason that apm isnt a kld is because nobody's done it? or does it have tendrils into too many things (apm_ioctrl() is a significant chunk of code ) for this to be possble or practical? likewise, is there anything in the way of making pnp a KLD? i am betting not, because there isnt a device for it in LINT or /dev, the only way it shows up is if you put options PNPBIOS or something in your config file straying further into vapourous work that i havent done yet... it seems to me that the program name 'pnpinfo' should be deprecated and the program should be called pnpconf ( like pciconf ) and follow pciconf's semantics as much as possible. pnpinfo would simply become a wrapper around 'pnpconf -vl' or something. and, taken to absurdity, would there be a perf hit if *everything* execpt malloc() and free() (showing my WinNT/WinCE professional experience here :-) ) where implemented as a KLD? tnx for listening! feedback appreciated... johnu -- John L. Utz III john@utzweb.net Idiocy is the Impulse Function in the Convolution of Life To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message