In message <3757c851.4...@cs.strath.ac.uk>, Roger Hardiman writes: >Hi there, > >Just a quick question. >I'm about to fix the cdevsw_add(&bktr_cdevsw); >bug in the brooktree848.c driver. > >Bruce wondered if this should go into bktr_attatch rather >than bktr_probe? > >What do you think? >I think _attach is better. Otherwise we will call cdevsw_add() >even if you have the bktr driver in the kernel and have no bt848 >card fitted
Today I don't much care where you put it. In the future we may want to think more about it though. The way I see it is that if the driver is there, it should check in at cdevsw[], which is why I generally put in *probe(). Of course if the hardware comes 'round later, attach will get called too. The next moves on my part are roughly: 1. Remove the difference between cdev/bdev dev_t's. I have a kernel running with this now, but there are bogons lurking which I have fumigated yes. 2. Enable doing "per dev_t" registration in the drivers. This will look pretty much like the devfs registration in there today, only more sane. After this the cdevsw_add() will only be kind of a "wildcard" registration method, for pseudo devices and such. After this point, a typical driver will probably do something like this: struct softc { int this; char that; bla bla bla }; /* some kind of probe/attach routine */ somefunction() { struct softc *sc; dev_t dt; dum di dah /* Aha, hardware! */ sc = MALLOC(...); bzero(sc, sizeof *sc); dt = mkdev( CDEV_MAJOR, /* Char major */ BDEV_MAJOR, /* Block major */ foomble_devices * 16, /* Minor */ &foomble_cdevsw, /* The cdevsw function vector */ "foomble%d", foomble_devices); /* printf like construction of name */ dt->driver1 = sc; dt->driver2 = foomble_devices; foomble_devices++; } foomble_open(dev_t dev, ...) { struct softc *sc = dev->driver1; int unit = dev->driver2; .... } -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message