From owner-freebsd-hackers Sat Jun 5 4:41:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 37E1D14EEA; Sat, 5 Jun 1999 04:41:16 -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 NAA55582; Sat, 5 Jun 1999 13:39:58 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Nick Hibma Cc: Bruce Evans , current@FreeBSD.ORG, FreeBSD hackers mailing list Subject: Re: cdevsw_add In-reply-to: Your message of "Sat, 05 Jun 1999 11:48:02 +0200." Date: Sat, 05 Jun 1999 13:39:58 +0200 Message-ID: <55580.928582798@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. -- 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-hackers" in the body of the message