Date: Tue, 1 Jan 2008 12:09:50 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <CC4D41C0-7CD7-47A8-8DA0-523B38C65B9A@mac.com> In-Reply-To: <200712311606.25424.jhb@freebsd.org> References: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net> <200712281500.55155.jhb@freebsd.org> <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 31, 2007, at 1:06 PM, John Baldwin wrote: >> Using the hints-way of describing hardware is just not going to >> fly in that case, because you're still keying off of device names >> and unit numbers. Let that be a consequence of the metadata, not >> an integral part of... (device.COM1.* does exactly that). > > Redo the 'at' hints like this (pci was already this way in the > existing hint > wiring stuff anyway, i.e. it's _not_ a new-bus device name in > 'at'). I'll > use all-caps to make it stand out: While I think that's a good thing, the confusion to the user when it comes to the unit number is already present. People already assume that if they have hint.sio.0.at="isa" that they expect to see device sio0. I fear that it's exactly the same with "device.COM1.at=ISA. If the 1 on COM1 is just a means to distinguish multiple COM devices, then it's much better to use a more structural approach, eliminate the unit and instead key-off of something that's truly identifying. In other words: hints historically mix the hardware description with the assignment of the driver and the unit number. Your proposal has the same flaws. The whole thing is just awkward for the user and impossible to implement unambiguously. > Bus drivers would be responsible for parsing the 'at' and deciding > whether or > not to "claim" a set of device properties. They may then either bind > those > properties to an existing device enumerated elsewhere (ACPI/PNPBIOS/ > PCI) > based on 1 or more property values or create a new device entirely > described > by the property values. This is the part I don't like. There's no clear definition of who or what is in control. In other words: how do we distinguish a description that is to amend or correct from a description that is to define a new device. That's the fundamental problem. In RDB terms: We're still combining unrelated pieces of information in a single table. It has problems. We already have them and we will not resolve them if we don't fix the fundamental problems. Seriously: you need multiple independent descriptions or tables. You need one to enumerate hardware -- a table that describes hardware not already described and ideally usable across OSes (just so that it's clear that there are no FreeBSD specifics embedded). You need another tabke to assign hardware to drivers (i.e. wiring) -- a table that's processed by the newbus architecture and bus drivers so that the wildcard nodes created as the result of enumerating the hardware are mapped to devclasses and are assigned unit numbers. You need a third table for driver- specific information -- a table that is consumed by drivers and which comtains flags, options or directives to the driver so that it can work with the hardware in question. With ACPI optional and describing the LPC bus, we probably want to be able to describe the LPC bus in case we don't use ACPI. This means we need some way to make hardware descriptions optional or to active descriptions conditionally. This is also a feature we can use to support SoCs: we enable hardware descriptions based on some CPU ID, board ID or through some other means. Let's just fix this right... -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC4D41C0-7CD7-47A8-8DA0-523B38C65B9A>