HEADSUP: The bigger cdevsw/dev_t picture
Poul-Henning Kamp
phk at phk.freebsd.dk
Sun Feb 15 04:08:18 PST 2004
You have seen me throw a number of kilopatches out for review/test in
the last week, and there is a couple more forthcoming.
This is my big ugly "dev_t refcount" source-tree being decomposed into
self-contained bites which hopefully makes review/test easier.
I am finalizing a mechanical patch which flips the sense of the
"D_NOGIANT" flag to become "D_NEEDGIANT", this will also go out
for review today I think.
The final bit of this package of patches will be a tiny patch which
goes over all makedev(9) and udev2dev(9) users in the tree and convert
them to the new world order where they only succeed if a dev_t was
already created with make_dev().
At that point I will release the integrated mega-patch for your
convenience.
This entire load of patches will be committed in rapid order followed
by a bump to __FreeBSD_version, probably next weekend.
When that has settled down a bit, I will send the meaty part of the
dev_t reference counting patch in review.
Background:
All this comes about because of device driver unloading. To be able
to tell that we can safely unload a device driver, we need to be sure
that a thread has not just entered the drivers open() routine but not
yet done anything useful there. To be able to check this, we need
to have a sort of reference counts on dev_t.
The way this gets implemented is that struct cdevsw{} presented to make_dev()
will get put on a linked list, and all dev_t's created against that cdevsw{}
will be hung off a list from the cdevsw{}. the dev_t will grow a reference
count field and functions to grab/release a reference will be added.
When destroy_dev() is called, the dev_t is removed from the list of the
cdevsw{} and added to the dead_cdevsw{} list, and when its reference count
decreases to zero, it can be released/recycled.
To unload a device driver, after doing any private EBUSY checks, the unload
code will check if any dev_t's hang off the cdevsw{}, and if this is not
the case, the driver can safely be unloaded. (safely with respect to
it's cdevsw that is).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the freebsd-current
mailing list