In message <[email protected]>, 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
[email protected] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-current" in the body of the message
