I am in the process of adding ref-counting and locking to dev_t,
and would very much prefer if we could get this step completed
soon before 5-STABLE gets branched.

All this will be transparent to the majority of device drivers, as
the refcounting will happen in the make_dev() and destroy_dev()
family of calls and normal drivers need not know more about it.

But there are a few remaining users of makedev() which get in the
way of this effort, and we must get these fixed.

Basically:

        1. Do not call makedev().

        2. If you do cloning, please look at the patches I posted
            for if_tun/if_tap for how to do it.

        3. If you do a "normal" device driver, cache the result
           from when you call make_dev().

        4. If you translate "foreign dev_t's", ie emulators or
           compat code, contact me.  I'm not sure I understand
           how this works and should work and we need to talk.

        5. If anything else or in doubt, ask me.

Can I see some volounteers and/or maintainers please ?

        ./alpha/osf1/osf1_misc.c
                badly named local macro ?

        ./compat/linux/linux_stats.c
        ./compat/svr4/svr4_types.h
                compat code, not sure that this is correct now.
                Must be supported by new "finddev" semantics.

        ./dev/ata/atapi-cd.c
                cloning related to root mount.
                gets fixed when phk GEOMify the driver.

        ./dev/sound/midi/midi.h
                Not sure.

        ./dev/nmdm/nmdm.c
                pseudo-cloning.  Should do real cloning.

        ./dev/syscons/syscons.c
                Related to console initialization.  Maybe tricky.

        ./dev/sound/pcm/dsp.c
        ./dev/sound/pcm/mixer.c
        ./dev/usb/ugen.c
        ./dev/usb/uscanner.c
                Failure to cache result of make_dev()

        ./dev/vinum
                Failure to cache result of make_dev() ?

Thanks in advance!

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to