Date: Sat, 5 Jun 1999 14:42:15 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Nick Hibma <nick.hibma@jrc.it>, Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG, FreeBSD hackers mailing list <hackers@FreeBSD.ORG> Subject: Re: cdevsw_add Message-ID: <Pine.BSF.3.95.990605143833.20899B-100000@current1.whistle.com> In-Reply-To: <55580.928582798@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 5 Jun 1999, Poul-Henning Kamp wrote:
> In message <Pine.GSO.3.95q.990605113837.15420Q-100000@elect8>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990605143833.20899B-100000>