Some Questions

[M. Warner Losh]

In message: <200510191126.26371.jhb at freebsd.org>
            John Baldwin <jhb at freebsd.org> writes:
: On Tuesday 18 October 2005 09:32 pm, Yong Ma wrote:
: > ----- Original Message -----
: > From: "John Baldwin" <jhb at freebsd.org>
: > To: freebsd-drivers at freebsd.org
: > Subject: Re: Some Questions
: > Date: Tue, 18 Oct 2005 11:17:51 -0400
: >
: > > On Tuesday 18 October 2005 04:26 am, Yong Ma wrote:
: > > > Hi everybody:
: > > >
: > > >
: > > > I'm new here,nice to meet you all! I'm also aFreeBSD_device_driver
: > > > newbie, and now I'm enaged in writting a driverfor a cryptographic
: > > > accelerator card.As a preparation I read thesections of device driver
: > > > in "FreeBSD Architecture Handbook",andexercised the example driver in
: > > > the book.now I have several questions(maybeeasy for you but most useful
: > > > for me):
: > > >
: > > > 1)Some drivers declares the device_open() as int device_open(dev_t
: > > > dev,...),and some declare it as int device_open(struct cdev
: > > > *dev,...),sometimes the first one couldn't be
: > > > compliedsuccessfully,what's the difference?
: > >
: > > On 6.0 and later you should use 'struct cdev *dev' and on 5.x and earlier
: > > 'dev_t dev'.
: > >
: > > > 2) if (pci_get_vendor(dev) == 0x11c1) { ...
: > > >                               ~~~~~~~~how to get this number if I don't
: > > > know it?
: > >
: > > This number is part of the chip ID in pciconf -l output.  For example, on
: > > my laptop:
: > >
: > > pcib1 at pci0:1:0: class=0x060400 card=0x00000000 chip=0x1a318086 rev=0x04
: > > hdr=0x01
: > >
: > > For this device, pci_get_devid(dev) would return 0x1a318086.
: > > pci_get_vendor(dev) would return the 0x8086 part of that.
: > >
: > > > 3)Could the device on PCI slot be listed by /pciconf -l /without
: > > > driver.
: > >
: > > You mean cutting out the pcib1 part from the line above?  You could
: > > always use something like awk, sed, or cut.  For example:
: > >
: > > % pciconf -l | cut -d @ -f 2
: > > pci0:0:0:       class=0x060000 card=0x56001558 chip=0x1a308086 rev=0x04
: > > hdr=0x00
: > > pci0:1:0:       class=0x060400 card=0x00000000 chip=0x1a318086 rev=0x04
: > > hdr=0x01
: > > pci0:29:0:      class=0x0c0300 card=0x56001558 chip=0x24828086 rev=0x02
: > > hdr=0x00
: > > ...
: > >
: > > > 4)The printf() seems not work under XWindow mode in functions like
: > > > deviec_prob or device_attach,how to make it work?
: > >
: > > Run 'dmesg' in your Xterminal to see the messages.  Alternatively, you
: > > can use the 'xconsole' program which should show the messages in its
: > > window.
: > >
: > > > 5)If only the pseudo-device in /dev can be destroyed with
: > > > destroy_dev(sc->dev0) in detach() function in a KLD driver? I can't do
: > > > that!
: > >
: > > I'm not sure what you are asking here.  You can't leave an entry in /dev
: > > around when your module is unloaded via kldunload since you would be
: > > removing the devsw and devsw functions that back that device resulting in
: > > a kernel panic the next time some process tried to use the /dev entry. 
: > > What exact problem are you trying to solve?
: >
: > There is a make_dev() in the attach() in my test driver,and a destroy_dev()
: > and a bus_generic_detach() in the detach(),but the later ones seems don't
: > work when I unload the KLD module,while the make_dev() works properly,so as
: > I load and unload the module,there are quite a few devices in /dev have the
: > same name(for me they are mypci0). Several days ago,I did a driver test of
: > a PSEUDO-DEVICE with the detach() works properly.I wander if it is because
: > of the real HARDWARE device this time ?
: >
: > this is my detach() function:
: >
: > static int
: > mypci_detach(device_t dev)
: > {
: >
: >     struct mypci_softc *sc;
: >     sc = (struct mypci_softc *) device_get_softc(dev);
: >     destroy_dev(sc->dev0);
: >     bus_generic_detach(dev);
: >     bus_release_resource(dev, SYS_RES_IOPORT, sc->rid, sc->res);
: >     printf("Mypci detached!\n");
: >     return (0);
: > }
: 
: Do any processes have /dev/mypci0 open when you try to kldunload?  You 
: probably should maintain a count of open clients and if it is > 0, return 
: EBUSY in my_pcidetach().

You don't need to keep a count of open clients, per se, since the vfs
layer will do that for you and the open/close pairs might not be
pairs.  The driver's close will only be called when all referneces go
away, unless you have D_TRACK_CLOSE in your flags...

In my drivers, I often use D_TRACK_CLOSE, call driver_busy in open,
and driver_unbusy in close.  I then check busy in detach and refuse to
detach if things are busy.

There are problems with doing this for detachable devices, because the
driver will be forcibly torn down if detach fails anyway....

Warner