From owner-cvs-all Tue Jul 20 12:16:40 1999 Delivered-To: cvs-all@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id BC9B0153BA; Tue, 20 Jul 1999 12:16:29 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id VAA21806; Tue, 20 Jul 1999 21:15:16 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/vn vn.c src/sys/kern kern_conf.c vfs_subr.c src/sys/miscfs/specfs spec_vnops.c specdev.h src/sys/sys conf.h param.h types.h vnode.h src/sys/ufs/mfs mfs_vfsops.c In-reply-to: Your message of "Tue, 20 Jul 1999 14:34:24 EDT." Date: Tue, 20 Jul 1999 21:15:16 +0200 Message-ID: <21804.932498116@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In message , Alfred P erlstein writes: >Any other reasons? Yes, several in fact. The primary goal is to get us to the point where we can have a daemon running which handles dynamic devices. You have already seen how much noise a pccard ethernet can make in the mailing lists when it comes to what should happen when it is plugged in, but that is only the beginning. In short we want to be able to run a "devd" which can be instructed to do what we want to happen when devices are attached or disappear on the fly. Another major goal is to get beyond the #define NFOO limitation for device drivers. Most device drivers can absorb any number of devices, but we have this "struct softc {...} sc[NFOO];" thing all over the place, and weird "devtofoo()" macros to unravel the minor device number into whatever is encoded there. The next step in this little operation will allow device drivers to do something like: foo_probe(...) { struct softc *sc; dev_t dev; peek; poke; check; if (!found) return nothing; MALLOC(sc, ...) sc->this = something; sc->that = something_else; dev = create_dev(DEV_CMAJ, my_unit * 8, "foo%d", my_unit); dev->driver1 = (void *) sc; dev->driver2 = (void *) 0; dev = create_dev(DEV_CMAJ, my_unit * 8, "foo%d.ctl", my_unit); dev->driver1 = (void *) sc; dev->driver2 = (void *) 1; dev = create_dev(DEV_CMAJ, my_unit * 8, "foo%d.reset", my_unit); dev->driver1 = (void *) sc; dev->driver2 = (void *) 2; my_unit++ } foo_open(dev_t dev, ...) { struct softc *sc; int subdev; sc = dev->driver1; subdev = dev->driver2; switch (subdev) { case 0: /* The real thing */ ... case 1: /* Control device */ ... case 2: /* Reset device */ ... } ... } At this point Alert readers have already looked at the devfs_add_devswf() calls and have started to mumble things I'm sure: And yes, that is the next place we can go with this. The fundamental design error in DEVFS was to "bolt it onto the side" (of something that's bolted onto the side of something that's...) I have not decided how to tackle this in details, but the one thing which is quite certain is that some kind of message passing when devices are created/destroyed will be needed to keep a user-land agent/daemon abreast with developments. I don't think we need to copy the entire route-table "protocol" approach, a less heavy-duty mechanism will do. But apart from that a some obvious overall cleanups presents themselves now that we have a central "per device" structure in the system: The tty pointer could be put there, and devtotty can go away. Pointers to disk slice/label data can be put there and much of the ds*() calls can leave the disk drivers and be put entirely at a generic level. I havn't looked (I'll leave that to others) but maybe the VM system (the device-pager ?) may want to hang a thing or two off the specinfo structure. We can implement a dev->name translating sysctl, and printfs in the kernel can print a canonical device name rather than some cryptic numbers. In the long run, block-devices can go away (seen from userland at least). if somebody wants to tackle any of these bits or other that they see, the field is open to everybody. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message