From owner-freebsd-hackers Wed Oct 18 21:16:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA20740 for hackers-outgoing; Wed, 18 Oct 1995 21:16:59 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA20716 for ; Wed, 18 Oct 1995 21:16:53 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id VAA10948; Wed, 18 Oct 1995 21:15:28 -0700 Message-Id: <199510190415.VAA10948@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Julian Elischer cc: moonhunt@easy.re.kr, hackers@freebsd.org Subject: Re: device number for watchdog board driver In-reply-to: Your message of "Wed, 18 Oct 1995 20:31:44 PDT." <199510190331.UAA21719@ref.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Oct 1995 21:15:27 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Now, if we could access this information along with a textual description of what the driver is supposed to do,version number of the driver and access this information via snmp we will be all set :) You see then we will have a generic interface to access the information not just locally but remotely from *different* machines. I believed that there is a mib interface for sysctl so we could use it as an example to export the driver information . Enjoy, Amancio >>> Julian Elischer said: > > > > > > Also not to mention that loadable modules are not listed... > > > > I was thinking more along the lines of : > > > > 25: sd1 at SCSI bus 0:6:0 (ready) (open) > > 4, 65546 /dev/sd1 > > 4, 8 /dev/sd1a > > 4, 9 /dev/sd1b > > .... > this is what devfs is for > with the added advantage that you can access the devices from there as well > for an axample: > freeway: {1} ls -lR /devs > total 0 > dr-xr-xr-x 4 root wheel 29 Oct 17 00:36 disks > dr-xr-xr-x 2 root wheel 96 Oct 17 00:36 misc > > /devs/disks: > total 0 > dr-xr-xr-x 2 root wheel 16 Oct 17 00:36 floppy > dr-xr-xr-x 2 root wheel 16 Oct 17 00:36 rfloppy > > /devs/disks/floppy: > total 0 > brw-r--r-- 2 root wheel 2, 0 Oct 17 00:36 fd0.1440 > > /devs/disks/rfloppy: > total 0 > crw-r--r-- 2 root wheel 9, 0 Oct 17 00:36 fd0.1440 > > /devs/misc: > total 0 > crw-r----- 2 root wheel 0, 0 Oct 17 00:36 console > crw-r----- 2 root kmem 2, 14 Oct 17 00:36 io > crw-r----- 2 root kmem 2, 1 Oct 17 00:36 kmem > crw-r----- 2 root kmem 2, 0 Oct 17 00:36 mem > crw-rw-rw- 2 root wheel 2, 2 Oct 17 00:36 null > crw-r----- 2 root kmem 34, 0 Oct 17 00:36 pmem > crw-r----- 2 root kmem 33, 0 Oct 17 00:36 tiga > crw-rw-rw- 2 root wheel 2, 12 Oct 17 00:36 zero > > as an example.. pmem and tiga > have no entries in conf.c > they added their own entries dynamically > and told devfs about it.. > devfs reports where they ended up (apparently they slotted themselves > in at 33 and 34) > > > I need to add about 10 lines of code to each device driver to make this > complete, but the one that is holding me back is the diskslice/disklabel > code, which needs a rather more complicated interaction with devfs, > and I haven't worked out what the best way of doing it yet is.. > > > > > You see as more drivers and/or loadable modules get added to FreeBSD > > it becomes rather nice to issue a single command to figure out what > > is on the system. > EXACTLY Why devfs is needed.. handles LKMS and other such things.. > for example a device might go into debug mode when given > a particular ioctl, and could create a debug device > on the fly.. (for debug info to come out of or something) > turning debug mode off again.. that debug device would dissappear again. > (If you had it open you would end up holding a vnode to the deadfs) > > > > > > > Enjoy, > > Amancio > > > > > > > >