This should definitely go into attach IMNSHO. Probe: Check whether hardware is there (no side effects if possible). Attach:Get the device up and running and integrated into the kernel.
With the priority probes this is even more distinct as a priority not equal to 0 means 'no side effects, just checking'. Nick. On Fri, 4 Jun 1999, Poul-Henning Kamp wrote: > 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 > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message