Date: Wed, 31 Jan 2001 23:29:59 -0800 From: Peter Wemm <peter@netplex.com.au> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Warner Losh <imp@harmony.village.org>, arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Message-ID: <200102010729.f117TxW09445@mobile.wemm.org> In-Reply-To: <XFMail.010131172705.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > Both have their roots in other places, and I get the feeling you > would like a logical tree tied directly to the devives, so that you > would have something like: > > int > device_get_attribute(device_t dev, const char *name, int *len, void *value); > > int > device_set_attribute(device_t dev, const char *name, int *len, void *value); > > Where 'name' is the name of a node under some arbitrary tree whose > immediately preceding branches are either 'foo0' or 'foo.0'. There is only one real problem, and it is a big one. At the point of device_probe, there is no name or unit set. "fxp0" does not exist until after the probe has finished and the bus mechanism has decided that the device auction is over. Until then, it is "unknown" unit -1. This means that the usual probe mechanism cannot take advantage of hints. There are some exceptions.. the isa bus does lots of magic and is driven by the unit name/number, rather than a detected resource. ISAPNP stuff would run into this problem more if the probe mechanism did anything more than matching the pnpid. If it did printf's etc they come out as: unknown-: <.....> This is not impossible to work around. And it needs it in order to be able to do decent wiring of devices. I still want to be able to wire IDE devices the same that we can wire scsi devices... only the scsi wiring is missing the ability to reserve (say) ahc0 for some specific pci slot. I have a fairly old checked out tree with this partially implemented somewhere. I had in mind a mechanism to merge the resources and device tree together, but keeping a persistant resource tree. The 'at' binding would be interpreted by the bus parent, for example. And the other resources would be available in a manner not too unlike the API above. It would work something like this.. Suppose: hint.fxp.0.at="pci0.6.0" hint.fxp.0.flags=0x100 hint.fxp.0.speed=100 hint.fxp.0.duplex="full" So, when pci0 was doing its probes and was about to assign a unit number for a "fxp" driver, it would scan for the at= and would check if the at= matched the current address. If so, it would try and give unit 0 to that instance. If not, it would find the next available unwired unit. Then.. for the instance that ended up with unit 0, the flags, speed and duplex attributes would be attached to that device, and the fxpattach stuff (and indeed the rest of the driver) could do a device_get_resource(dev, "speed", RES_INT, sizeof(speed), &speed) Note there are several keys to this.. - the driver should tell the framework what sort of "thing" it wants.. ie: interpret the resource as an int, or give me a string, or whatever. - the key for the at= bindings is that the parent must decide if it is a match or not. We cannot know ahead of time what the tree geometry is going to look like, so we have defer it till the last minute. the pci driver would see "pci0.6.0" and decide that yes, we are "pci0" and that we are currently looking at device 6 function 0, so we are matching this set of resources. Hmm, in fact, there is nothing much stopping this stuff being available to the probe routine either.. we could temporarily assign a unit and name to the device instance that matched the driver that the probe was being done for. The scsi bus implementation of this stuff is really evil and although it works, it needs to be cleaned up and nicely encapsulated so that the same gross hackery isn't needed in every bus device. :-( Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102010729.f117TxW09445>