From owner-freebsd-current Sun Sep 3 17:43:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id RAA07513 for current-outgoing; Sun, 3 Sep 1995 17:43:54 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id RAA07507 for ; Sun, 3 Sep 1995 17:43:52 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA04142 for ; Sun, 3 Sep 1995 17:43:49 -0700 To: current@freefall.FreeBSD.org Subject: devinfo - Houston, we have a small crisis here.. Date: Sun, 03 Sep 1995 17:43:48 -0700 Message-ID: <4140.810175428@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk Background: In the 2.0.5 sysinstall, I find out which devices the user has by rather evil means: I rush around trying to open everything I can and, if I'm successful, I declare that device "found." For network devices, I walk the ifc_req chain. This has some serious drawbacks, the most notable being that only devices which can be "opened" may be probed this way (e.g. if you have a tape drive, this only works if there's a tape in it). It's also not a good method to use once the system is up, so it prevents you from really being able to use sysinstall afterwards - something that many people have asked for. I'd always intended to change this to grab the device list more the way lsdev(1) does it, but my hoped-for salvation there now appears to be imperiled by the fact that many important devices (like de0 and all CDs, SCSI disks and tapes, as I've so far found) just don't register the appropriate information. HELP! This is really going to screw me up! Finding devices by opening them is really insufficient and doing them this way was always my future hope - I just made the mistake of thinking that it would be trivial when the time came. If we have less than 100% coverage of devices registered under the proper classes (since I need to be able to subpartition the array of devices the user is presented with in certain situations by class) then trivial it most certainly won't be, I can tell you that. Gah. I don't want to keep using the 2.0.5 method - it's known to be broken in many ways! :-( Can I interest any of you in a short, quick push to clean up any missing or insufficient dev_attach() functionality in our current driver set? I'm willing to go do some of the work *myself* as necessary (and lordie knows I'm no kernel hack) but if I can count on at least some driver authors taking this task over for their own drivers, that's that many less I have to worry about. Garrett: How come the set of device classes is wider with devmenu? It uses dc_class whereas lsdev uses the more restricted machdep_devtype from instead of . If there is some rhyme or reason to this, I'm not seeing it! :-( Thanks! Sorry to bring this up at such a late juncture, but I was just being stupid and assuming that this worked all along and could just be picked up when the time came. The mechanism certainly isn't that difficult to use from the sysctl() perspective, I just need all the information to be there and properly classed or some users aren't going to see their devices listed in places they'd really like them to be listed! :-( Jordan