Re: HEADSUP: Change of makedev() semantics.
On Sun, 28 Sep 2003, Poul-Henning Kamp wrote: > 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. > show an actual document please, explaining how this works from the user's POV.. > 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. more docs on how you invisage clonign to work. > > Can I see some volounteers and/or maintainers please ? > > ./dev/nmdm/nmdm.c > pseudo-cloning. Should do real cloning. > If the documentation is easily available and it does what I want I'll convert it.. It may be available but I haven't seen it.. man make_dev(9) doesn't have any 'see also' section that helps.. So, why should I not revoke a vnode that now refers to nothing? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: Change of makedev() semantics.
In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey" writes: > >--yRA+Bmk8aPhU85Qt >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: >> Basically: >> >> 3. If you do a "normal" device driver, cache the result >> from when you call make_dev(). >> ... >> >> ./dev/vinum >> Failure to cache result of make_dev() ? > >Where should this be cached? Can you point to example code? Almost any other device driver. It is usually stored in the softc structure. -- 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]"
Re: HEADSUP: Change of makedev() semantics.
On Sunday, 28 September 2003 at 19:46:20 -0400, Robert Watson wrote: > > On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: > >> On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: >>> Basically: >>> >>> 3. If you do a "normal" device driver, cache the result >>>from when you call make_dev(). >>> ... >>> >>> ./dev/vinum >>> Failure to cache result of make_dev() ? >> >> Where should this be cached? Can you point to example code? > > Actually, it looks like Vinum is caching the dev_t's, Ah, you mean saving the results rather than calling make_dev() every time? Yes, it only calls make_dev() once for any device. > but it's not always using them to get back to the dev_t--sometimes > it's invoking makedev() instead. However, this appears to happen > only in the vinumrevive.c code, so I'm not sure if that's a property > of the cached reference being unavailable it looks like it should be > available in that context though. No, it should always be available. I was going to say "I don't see any references to make_dev() in vinumrevive.c, nor any references to makedev() at all", but I see that VINUM_SD includes both. > I.e., using sd->dev instead of VINUM_SD() -- it looks like there is > a valid (struct sd *) reference there to follow, so you can get to > the dev_t without doing a makedev(). Yes, this is a bug (and an indication of the dangers of using macros :-) I'll fix it. Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. pgp0.pgp Description: PGP signature
Re: HEADSUP: Change of makedev() semantics.
On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: > On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: > > Basically: > > > > 3. If you do a "normal" device driver, cache the result > >from when you call make_dev(). > > ... > > > > ./dev/vinum > > Failure to cache result of make_dev() ? > > Where should this be cached? Can you point to example code? Actually, it looks like Vinum is caching the dev_t's, but it's not always using them to get back to the dev_t--sometimes it's invoking makedev() instead. However, this appears to happen only in the vinumrevive.c code, so I'm not sure if that's a property of the cached reference being unavailable -- it looks like it should be available in that context though. I.e., using sd->dev instead of VINUM_SD() -- it looks like there is a valid (struct sd *) reference there to follow, so you can get to the dev_t without doing a makedev(). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: Change of makedev() semantics.
On Sun, Sep 28, 2003 at 11:22:07PM +0200, Poul-Henning Kamp wrote: > > 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 ? Unused code. umakedev is used within a macro but nowhere defined it seems. makedev is used as a macroname, but ifdef'ed 0. Shouldn't hurt. Maybe someone with knowledge about OSF1 emulation should decide what happens with them in the long run. > ./dev/usb/ugen.c > ./dev/usb/uscanner.c > Failure to cache result of make_dev() I'll take those. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: Change of makedev() semantics.
On Sunday, 28 September 2003 at 23:22:07 +0200, Poul-Henning Kamp wrote: > Basically: > > 3. If you do a "normal" device driver, cache the result > from when you call make_dev(). > ... > > ./dev/vinum > Failure to cache result of make_dev() ? Where should this be cached? Can you point to example code? Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. pgp0.pgp Description: PGP signature
HEADSUP: Change of makedev() semantics.
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]"
