Date: Wed, 6 Aug 1997 11:03:13 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: Registry reviewers? Message-ID: <199708060133.LAA01644@genesis.atrad.adelaide.edu.au> In-Reply-To: <199708051624.JAA06304@phaeton.artisoft.com> from Terry Lambert at "Aug 5, 97 09:24:42 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > Do I take it that nobody has actually looked at the registry code > > (documented, commented for Steven's delectation) that I mentioned > > last week? ... > I saw the announcement, but have not grabbed the code. > > Do you have a higher level architectural overview? Not on paper, no. To put it very simplisitically : Intent: - To provide a uniform, managed namespace for in-kernel data resources. - To address some of the shortcomings of the sysctl mechanism, most particularly support for more complex datatypes and method-based access. Principal consumers: - Parameter-hungry subsystems (PCI, PnP, PCCARD, network interfaces, etc.) - User-space applications wishing to access/manipulate kernel-private data. Structure: - We have a period-delimited hierarchical namespace, with support for lookup by name or by oid (for sysctl compatability). - Nodes within the namespace may have attached access methods. - Access methods are keyed by name/type, requested data type, etc., ie. a node may have a number of access methods. - Support is implicit for single values, arrays and pointers, as well as methods that have no data per se. > For example, are you doing kernel level file I/O to implement the > thing? No. At this point, I haven't gone so far as to support marking individual nodes or methods as pageable or otherwise; if this becomes desirable, the correct way to implement it would be with pageable kernel memory IMHO. There are issues related to tree/chain transit as well with pageable registry entries that I didn't want to get involved with at this stage. > I've personally been working on Win95/NT style registry API's at the > kernel level (a necessary step to support use of Win32 Ring 0 drivers > in FreeBSD), so I've basically ignored code-level reviews of such things. Fair enough. I would be interested to know what sort of infrastructure support that kind of API would require. > My personal preference is an LDAP database accessable from user or > kernel space, or remotely via an LDAPd. I have not seriously pursued > this because of the (apparent) NDBM requirements. Whilst LDAP is quite a desirable goal to pursue, the principal thrust of this code is to address parameter management for subsystems which lie too low down for LDAP lookup to be useful, eg. drivers, fundamental network configuration, etc. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708060133.LAA01644>