From owner-freebsd-hackers Sat Jun 5 14:42:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 75F7F14BD5; Sat, 5 Jun 1999 14:42:36 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id OAA02335; Sat, 5 Jun 1999 14:42:16 -0700 (PDT) Date: Sat, 5 Jun 1999 14:42:15 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp Cc: Nick Hibma , Bruce Evans , current@FreeBSD.ORG, FreeBSD hackers mailing list Subject: Re: cdevsw_add In-Reply-To: <55580.928582798@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 5 Jun 1999, Poul-Henning Kamp wrote: > In message , Nick Hibma writes: > > > >While on the topic: Who is working on devfs and why not? > > > > > > I'm not currently working on devfs, but I am building the infrastructure > > > it should be based on in the kernel. > > > >Anymore information available on where you are with this? > > I currently have a kernel running where dev_t is a pointer to a > "struct dev" and where char and block devs are collapsed at the > dev_t level. There are some bogons i need to fumigate, but I'm > off to give a course in Stockholm much of this coming week, so > don't expect any commits just now. (I may actually postpone/abandon > this step for now, since some of the changes pulls rugs away which > cover what looks to me like holes in the floor). > > Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing > code. > > When I have that bit down and done, the next step is for device > drivers to register individual dev_t's rather than blanket cdevsw > entries. The later ability will be retained for pseudo drivers > and other (pseudo)magic. > > This registration will look pretty much like the current #ifdef'ed > DEVFS stuff, and in addition it will allow the driver to hang two > fields of the dev_t, typically a pointer to the struct softc and > maybe a unit number or something. This will obsolete all of > the magic minor -> {unit|softc} converters in our drivers and > make the "NFOO" configuration obsolete. > > That is, as such the end of this little project, and where a future > DEVFS could take off from. Basically all that is needed for a DEVFS > to do, is to hook into the dev_t maintenance code and construct > the directory tree. DEVFS has always meant to do exactly this. there is already a place in the structure for these two fields, and when devfs is running, the devsw[] table is not consulted. The vnode already contains a direct pointer to the devsw entry and a cookie (minor number), and these are called directly. there is already a node type for the 'unified' device type. there are three types of device in devfs BDEV, CDEV and DDEV. DDEV has only a pointer to teh methods and a cookie. (as you suggest above) > > -- > 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 freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message