Garrett D'Amore writes: > On Sun, 2007-08-19 at 20:11 -0400, Andrew Gallatin wrote: > > Garrett D'Amore writes: > > > On Sat, 2007-08-18 at 20:58 -0400, Andrew Gallatin wrote: > > > > Garrett D'Amore writes: > > > > > On Fri, 2007-08-17 at 20:39 -0400, Andrew Gallatin wrote: > > > > > > Hi, > > > > > > > > > > > > I have a GLDv2 ethernet driver which I need to add some > > > > > > OS-bypass functionality to. I'm porting this from Linux, > > > > > > where the linux ethernet driver creates a character device > > > > > > for mmap/ioctl access to this functionality. > > > > > > > > > > > > I'm somewhat concerned, as it looks like GLD (or something) > > creates a > > > > > > /dev/drivername character device. Does GLD (or whatever) us *my* > > > > > > cb_ops struct for this, or its own? Am I allowed to make the > > cb_open, > > > > > > cb_close, cb_devmap and cb_ioctl pointers in my driver's cb_ops > > > > > > structure non-null, and use them (in conjunction with > > > > > > ddi_create_minor_node()) for this new functionality? > > > > > > > > > > > > If not, how can I get a device node for mmap/ioctl access? > > > > > > > > > > The classic way of doing this is to create a second driver, which > > > > > depends on the code from the first (link with -N drv/mydriver or > > > > > somesuch), but exports its own cb_ops. > > > > > > > > Drat. In previous projects, the 2 driver approach has been nothing > > > > but a PITA, I was hoping to avoid it this time. > > > > > > Heh. Yeah, its kind of annoying... I've run into this problem myself > > > before. I wound up using two drivers in both cases in my past. > > > > > > There are challenges for dealing with Dynamic Reconfigure (DDI detach, > > > etc.), but nothing insurmountable. > > > > That is exactly the problem I remember. Is using ldi_open_by_name() > > in the secondary driver the generally accepted way to ensure that > > the primary driver doesn't get auto-unloaded out from under the > > secondary driver? > > Well, there are two problems. The first is the driver being unloaded > (the code). Linking with -N takes care of that problem automatically.
Yes. > The second problem is making sure that the device *instance* isn't > removed. In the past I've handled that by doing my own reference > counting... e.g. have the 2nd pseudo-driver register its usage > (increment a reference count) in the hardware driver, and have the > hardware check that before doing anything substantitve in DDI_DETACH > handling. (Note that you probably also need to have a flag or a lock to > block out subsequent registration attempts from occuring concurrently to > your DDI_DETACH processing.) I think that's what the ldi_open_by_name was trying to do. In the old project, the streams driver was secondary, and the cdev driver was primary. The cdev driver would block detach if anybody had it open. > I can try to locate some code or hack some sample up if you're not sure > exactly how to do this. That would be great, as I'm afraid some of the assumptions from the previous project will not be true now that a streams driver is primary, and a cdev driver is secondary. Thanks, Drew _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
