Date: Fri, 4 Jun 1999 15:09:01 +0200 (MET DST) From: Nick Hibma <nick.hibma@jrc.it> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Roger Hardiman <roger@cs.strath.ac.uk>, current@FreeBSD.ORG Subject: Re: cdevsw_add Message-ID: <Pine.GSO.3.95q.990604150606.15420d-100000@elect8> In-Reply-To: <3929.928500855@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.446B@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
> phk@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 majordomo@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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.95q.990604150606.15420d-100000>