Date: Tue, 17 Oct 2000 04:28:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@wintelcom.net (Alfred Perlstein) Cc: tlambert@primenet.com (Terry Lambert), gcorcoran@lucent.com (Gary T. Corcoran), freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Module parameters? (WildWire DSL card driver) Message-ID: <200010170428.VAA06237@usr01.primenet.com> In-Reply-To: <20001016194147.I272@fw.wintelcom.net> from "Alfred Perlstein" at Oct 16, 2000 07:41:48 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > #define D_TRACKCLOSE 0x80000 /* track all closes */ > > > > Under what circumstances is it permissable to _not_ set this bit? > > > When you want the old behavior. > > Under what circumstances is it permissable to want the old behaviour? > > Jeez Terry, I don't know, it's how it used to be so I assume it's for > compatibility or for drivers that simply don't care. Am I missing > something here? I guess I'm asking "What moron would want to intentionally disable system resource tracking?". It's OK for the driver to not care, I guess, if it doesn't want to allow you to unload it, and other evil things. I can maybe buy the legacy argument, but, frankly, and I said this when Poul and David first asked that the capability to track closes first went in, unless everyone plays by the same rules, no one benefits. I guess it'd be nice if it weren't possible to have new drivers not support device close tracking, even if they did nothing about it, other than disallowing unloads when the open count was positive. In the specific context of this thread, if there was a control daemon, then the first open could always be the control daemon, and "attach" parameters could be passed by doing an open, noting it was the first open, and delaying the attach until the open count went from 1->2. For symmetry, this means that if I want to change the parameters after a reconfiguration, I need to know when the open count has gone from 2->1 (leaving only the control daemon). In order to differentiate the control daemon failing, from a normal non-control close, I would need to track and maintain a list of who the opener is, and remove from that list on close. As a general approach, this removes the need for a seperate control and usage device distinction, for those devices which have it now. It also means that I can distinguish a control open from another open, and that I can wedge an open in through an ioctl() to let me do things like have opens onto the ISO9660 and DVDROM views onto a DVD, without having to have seperate character and block devices, so tat, given a legal codec, I can play DVDs on FreeBSD, just like you can on MacOS X (which uses the caharcter device for one type of access, and the block device for the other: efectively another control device hack). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010170428.VAA06237>