From owner-freebsd-arch Wed Jan 31 21:47:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C914D37B491; Wed, 31 Jan 2001 21:46:54 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f115ks928525; Wed, 31 Jan 2001 22:46:54 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102010546.f115ks928525@harmony.village.org> To: John Baldwin Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 31 Jan 2001 17:27:05 PST." References: Date: Wed, 31 Jan 2001 22:46:54 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : Well, I don't think that env.hint is any better of a dumping ground than hw. :) : 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: Yes. I would. hw.snd moves some meta information to a different part of the tree than other meta information. : 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'. Yes. That's right. I'd be tempted to have it be the full path to the device, but that doesn't make a lot of sense given that devices are uniquely named. : If you allow implicit creation of attributes, then that API might be : enough, so long as when a device goes away, it's entire tree goes : away. Another choice might be to require explicit adding/removing : of per-device attributes. You also might want to have devclass : attributes (the pcm snd_unit is an example of this.) I wouldn't want the whole tree to go away when the device went away. I'd like to see it persist after the device goes away. This would allow me to have a TV card, say, come up in PAL mode all the time. Or my removable ethernet always prefer thinet over 10baseT. I'd like to have some way of know which attributes a driver supports so that a generic tool could configure them easily. Hints right now doesn't allow for this. The drivers fetch the resource and that's that. If you spelled something wrong, you have no way of knowing it other than the device not changing its behavior. : Is this what you are looking for? A lot closer. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message