Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jan 2001 22:46:54 -0700
From:      Warner Losh <imp@harmony.village.org>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        arch@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/dev/ata ata-disk.c 
Message-ID:  <200102010546.f115ks928525@harmony.village.org>
In-Reply-To: Your message of "Wed, 31 Jan 2001 17:27:05 PST." <XFMail.010131172705.jhb@FreeBSD.org> 
References:  <XFMail.010131172705.jhb@FreeBSD.org>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <XFMail.010131172705.jhb@FreeBSD.org> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102010546.f115ks928525>