Date: Tue, 20 May 1997 21:01:58 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: dfr@nlsystems.com, current@FreeBSD.ORG Subject: Re: Backwards compatibiliy for isa_driver Message-ID: <19970520210158.29500@x14.mi.uni-koeln.de> In-Reply-To: <199705201304.WAA02736@genesis.atrad.adelaide.edu.au>; from Michael Smith on Tue, May 20, 1997 at 10:34:07PM %2B0930 References: <19970520135613.55522@x14.mi.uni-koeln.de> <199705201304.WAA02736@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 20, Michael Smith <msmith@atrad.adelaide.edu.au> wrote: > 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. Well, it depends ... :) All I was after, in the beginning, was a way to specify that a PCI device is wired to some PCI slot. I wanted to have a way to make the following config lines work: controller pci0 controller pci1 at pci0 slot 4 # PCI to PCI bridge ... The table might be identical to the one defined for SCSI devices, but I didn't like a structure in some machine dependent format, and thus thought about a way to use a text file that can be scanned with little overhead. I wondered whether it is possible to make the text file become a general repository. Thinking about this, I found that a simple textual representation was a vector of integers, with the "at XXX" specifying the semantics of the data, and the device name being an selector. This works for PCI, but it is obvious that the same data format could be used for the "wiring" of SCSI devices to controllers, and in fact also to keep the config data of an ISA device. Lets look at a sample configuration: controller pci0 controller pci1 at pci0 slot 4 # PCI to PCI bridge ... device ahc0 at pci1 slot 0 func 0 device scbus0 at ahc0 device sd0 at scbus0 target 2 device sd1 at scbus0 target 3 device ahc1 at pci1 slot 1 device scbus1 at ahc1 device sd2 at scbus1 target 0 device ed0 at isa? port 0x280 irq 5 I've implemented access functions that would expect the above to be encoded as: what name unit data # interpretation of data --------------------------------------------------------------------- pci pci 1 0 4 # bus,slot pci ahc 0 1 0 # bus,slot ahc scbus 0 0 # unit scbus sd 0 0 2 # SCSI bus scbus sd 1 0 3 # SCSI bus pci ahc 1 1 1 # bus,slot ahc scbus 1 1 # unit scbus sd 2 1 0 # SCSI bus isa ed 0 -1 -1 5 0x280 # bus(any) drq(none) irq port I have on purpose not bound any semantics to the data, other than that implied by the code that retrieves the vector for eg. (isa,ed,0) and assumes to find irq, drq, attach port, ... in the result. There should be sysctl functions that decode the configuration data, and those know how to label and represent the values. If a type (ie. ID used in the "what" column) is unknown to the sysctl code, then a "kern.cfg.WHAT.NAME.UNIT: (DATA)" will be printed ... > 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). Yes, I was also thinking about a pure text file. I expect that file to be loaded by the boot loader (which already reads the file /boot.config before loading the kernel) and be copied to a well known physical memory location, where the kernel will find it. The kernel should then copy the file contents into kernel VM, and use the data for pre-userconfig initializations. > 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. I prefer records, who may point at other records ... > - 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. Yes, I see. I could encode the same information with the method I propose, but it would consume more space ... Well, I could do it in the same amount of space, if I think about it :) > 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. Yes, I see ... I could easily modify my current repository scanning code to read just that format. The node would specify my "what" value, the "name" would be my "name", a unit would not be used, and a comma seperated list of integers could be returned. The major difference is, that the code that select the nodes must know about appending the unit number to the driver name to build a node name that is specific to a device instance. So, what you suggest seems to be a subset of what I already offered :) > 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. Hmmm, how big is the risk of the boot failing, if we start to probe at these "hint" addresses ? Probing for the interrupt to use seems especially dangerous ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970520210158.29500>