HEADSUP: The bigger cdevsw/dev_t picture

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.