Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jan 2001 18:04:18 -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:  <200102010104.f1114I927261@harmony.village.org>
In-Reply-To: Your message of "Wed, 31 Jan 2001 16:25:06 PST." <XFMail.010131162506.jhb@FreeBSD.org> 
References:  <XFMail.010131162506.jhb@FreeBSD.org>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <XFMail.010131162506.jhb@FreeBSD.org> John Baldwin writes:
: This is why I think ACL's for sysctl's that are administered via a sysctlfs
: wouldn't be such a bad thing.

I think that it is significantly more difficult a problem than you
might think.

: However, I think that, say, hw.snd.pcm0.hwvol_mixer, is more of a hardware
: attribute then a kernel environment attribute, which env.hint.pcm.0.hwvol_mixer
: kind of implies.  I don't see env as being a good dumping ground for hardware
: configuration, so I'd almost rather have devices export any important
: information via a sysctl that lives in the proper part of the sysctl tree
: rather than just stuck under env.

I respectfully disagree.  While we are using the kernel environment
for this, that's just an unimportant implementation detail.
hint.pcm.0.hwvol_mixer implies to me an attribute of unit 0 of pcm.
With the hw.snd tree, you have to look in many places for the meta
information for the device.  Some stuff is in the config space, some
stuff is in the snd tree, and other stuff is who knows where.  That
makes it hard to implement a generic meta information editor and
infrastructure.

: Also, for dynamic sysctl's, it is easier to
: use 'pcm0' for a node than a '0' node under a 'pcm' tree.  This is because
: device_get_nameunit() gives us a string we can just pass to sysctl_add_oid(),
: whereas device_get_unit() returns an integer that we'd have to malloc a string
: for and sprintf() into or something.  (I guess we could do _really_ evil things
: where we return a pointer into the nameunit string that starts with the unit
: number).

This precludes us from having device names that end in a number.
That's currnetly supported and works well, at least for loadable
modules.

I think that drivers have no business using sysctl directly.  We need
to have a good system that allows them to get hierarchical information
dynamically.  It may be the case that this is done with sysctl under
the covers, it may not.  Since it would likely be universal and easy
to use, arguments about the relative ease of implementation at this
level likely aren't going to be very important at all.

If we enhance the device interface to allow this, it wouldn't matter
how thigns were implemented.  Right now kernel environment variables
are a handy communication device between the loader and the kernel
such that no changes were needed there.  Once they are into the
kernel, the way the work are an implementation detail that really
should be ignored for designing a good interface for driver writers to
use.

I'll admit that the current interface for resource_int_value and
resource_query_string are poorly documented.  They also don't allow
for easy setting once the probe/attach code has run.  We need to fix
that.  I'm of the mind that we need to have a single, unified tree
(maybe managed by sysctl, maybe not).  That tree would then cause
callbacks to the drivers to happen when the values in them change so
the driver can react to them or ignore them as they happen.  The
sysctl tree could be used for this behind the scenes updating.
Drivers could register those items that it understands.  This would
easily allow us to write a generic meta data editor.

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?200102010104.f1114I927261>