Date: Tue, 20 May 1997 22:34:07 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: se@freebsd.org (Stefan Esser) Cc: dfr@nlsystems.com, msmith@atrad.adelaide.edu.au, current@freebsd.org Subject: Re: Backwards compatibiliy for isa_driver Message-ID: <199705201304.WAA02736@genesis.atrad.adelaide.edu.au> In-Reply-To: <19970520135613.55522@x14.mi.uni-koeln.de> from Stefan Esser at "May 20, 97 01:56:13 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
My apologies for not keeping pace with this thread; I've been travelling insane distances and working stupid hours trying to get myself through a course I should probably never have enrolled in. Stefan Esser stands accused of saying: > On May 20, Doug Rabson <dfr@nlsystems.com> wrote: > > I realized this as soon as I started implementing it. I now have two > > kinds of operation on a bus, operations which read and write config data > > and operations which manipulate resources. The driver never accesses > > config data directly (no accesses to struct isa_device) which allows the > > bus to change data format or add instance variables while maintaining > > binary and source compatability with old drivers. > > Ok. This seems the right way to do it ... Um, I don't like this at all, or, more specifically, I don't like some of the implications of this. In particular, I'm not so keen on the storing of data by the "registry" in a format that is proprietary to the consumer. Think about it for a moment - without consumer-specific access methods, the data can't be manipulated. The consumer may not be present in the kernel, or in the external repository-manipulating tool to provide these methods when the data is to be manipulated. This is Bad. Given the paucity of data that we are talking about, and the relative infrequency with which it is likely to be accessed, I would actually be very keen to see it stored as flat text, or using a very small number of basic data types. (flag, integer, string). The model I had partially visualised went something like : - The basic entity in the registry is a node. - Nodes are organised in a hierarchial fashion, using some punctuation as a level seperator. Dots are currently trendy. - A node may have Attributes, which are name:value tuples. These can be used to attach standard details to nodes, or to store custom information. As an example, consider the ISA device driver data : sys.hardware.bus.isa.ed0 port_range = 0x300,0x31f irq = 5 state = active sys.hardware.bus.isa.ed1 port_range = 0x340,0x35f irq = 9 memory_range = 0xdc000-0xdffff state = active sys.hardware.bus.isa.probe_hints.ed port = 0x300 port = 0x320 port = 0x340 irq = 5 irq = 9 irq = 11 So we have a convention for nodes under bus.isa that they may use some or all of port_range, memory_range, irq and are required to have state attributes. Then we have a collection of nodes with ISA probe hints. The 'ed' driver would read the probe hints, and then create 'ed' instances as it found devices. If the probe hints were in a standard format, you could write an ISA helper function to iterate through the various valid combinations. I'd love to write more on this, but a) this link sucks, and b) I have about three hours to write a web page and two user manuals in two formats. 8( -- ]] 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?199705201304.WAA02736>