Date: Tue, 01 Jan 2008 18:49:09 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: xcllnt@mac.com Cc: freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20080101.184909.195750479.imp@bsdimp.com> In-Reply-To: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> References: <CC4D41C0-7CD7-47A8-8DA0-523B38C65B9A@mac.com> <20080101.135825.1943337000.imp@bsdimp.com> <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel,
thanks for taking the time to engage with me on this. The first part
of my message does correct a couple of misconceptions you have, and
may sound a bit argumentative. Sorry if it does. The second part
looks to ways to incorporate your ideas into a good replacement scheme
that would allow for richer expression.
In message: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com>
Marcel Moolenaar <xcllnt@mac.com> writes:
:
: On Jan 1, 2008, at 12:58 PM, M. Warner Losh wrote:
:
: > In message: <CC4D41C0-7CD7-47A8-8DA0-523B38C65B9A@mac.com>
: > Marcel Moolenaar <xcllnt@mac.com> writes:
: > : Let's just fix this right...
: >
: > In many ways, you are complaining about the same thing that I've
: > struggled with. Sometimes, hint.sio.0.addr=0x3e8 means 'bind
: > whichever of the enumerated COM ports lives at 3e8 to sio0' (eg, cross
: > binding of a device enumerated by other means to a driver/unit) and
: > sometimes it means 'you have a COM port whose resource starts at
: > 0x3e8'.
:
: Yes. We're going to use hints for too many things without making sure
: that a certain statement, assertion or rule is unambiguous.
:
: > I disagree with you that it is a fundamental flaw in the system, but
: > am always open to better suggestions at how to implement this stuff.
: > The hints were my first, best guess, and they have served us well.
:
: Yes, but...
:
: In the beginning, hints were used to let drivers know where to look
: for hardware. They were hints to the drivers so that drivers knew
: where to probe. Possibly before probing a fixed list of I/O ports
: where the ISA card could be configured to reside.
In the beginning (when newbus was introduce circa 3.0) they were used
by the busses to assign resources to the drivers they were adding. It
just turned out that the 'hints' were compiled into tables the drivers
used. In 4.x, the hints migrated from the config file to a text file
called typically device.hints. Throughout these underlying changes,
the drivers have never really known about resource hints. The bus is
the only thing that parses and consumes them (the busses were changed
from using the compiled in tables to using hints in 4.0). The ISA bus
used to be the only one that looked for the 'at' key with a value of
'isa' or 'isa0', and it used that to populate the children on the isa
bus. The drivers whose nodes are added to the tree as hints have no
idea that the resources came from hints or from some other enumeration
mechanism. They just call bus_alloc_resource and they get the
resource.
The removal of probing a fixed list of I/O ports happened at the same
time that newbus was introduced into the system. There may have been
one or two stragglers after we did the bulk of this work, but nearly
all of it was done when newbus was committed.
See devinfo -v on my system:
isa0
ppc0
sc0
sio1
sio2
sio3
vga0
orm0
I do not have the sio or ppc drivers in my kernel at all, yet they
appear to be bound to nodes in the tree by virtue of the hints that
are present in device.hints. This is what allows the drivers to
attach to nodes in the system if I were to dynamically load them.
: The key point of that statement is that the drivers were already
: there. They were compiled-in by virtue of the kernel configuration
: that already included bus attachment information and resource lists.
: The hints didn't cause the instantiation of a driver!
Actually, they did. You are confusing the code that's in the kernel
to device nodes in the tree. The hints will *ALWAYS* be there, even
when the appropriate driver isn't compiled into the tree. The device
nodes in the device tree will be there, unattached.
: This is not what's happening now. Hints cause driver instantiations
: and as such are much more significant than originally designed.
: They stopped being hints and turned into something much less well-
: defined.
What is happening now is what has always happened.
: > We
: > are at the point now where we must expand them either as John has
: > outlined, or we need to scrap them entirely in favor of something
: > better. What we cannot do is let the promise of something better that
: > isn't really being worked on stop us from expanding what we have.
:
: It has nothing to do with the promise of something better. It
: has everything to do with understanding of the problems.
:
: Put differently: extending what you have because you don't want
: to put in the effort of understanding the problem and working out
: how such could be solved is ultimately worse, because you end up
: with something that's not broken enough to fix but which will
: always cause you problems -- problems you can only accept because
: the alternative was not even considered.
We can't let your aesthetic objections to the system that's basically
working today block further efforts. I hate to be so blunt about it,
but we as a project have gone more with a rough consensus and working
code over a pie in the sky perfect design with no implementation.
Having said that, I'm willing to consider an alternative, but it has
to handle the functionality that hints handle today.
: > Do you have something specific in mind that we can start working on
: > some kind of design document against?
:
: I don't have a design document, but I have mentioned in various
: emails what I think we should be doing. Unless there's sufficient
: agreement on the rough course of action will I be working on
: details.
:
: > It is OK if that's a series of
: > conversations, but we have to get off the inflection point we're at
: > now: No, you can't expand what's there, and there's no clearly
: > articulated 'something better'.
:
: I have been conversing. I have been expression my point of view.
: What I have not seen, until now, is an actual statement of intend
: to just look at it from a different angle and see if we can come
: up with some set of requirements. Everything so far has been
: pivoting around hints. We have them and we're extending them.
: What about letting the discussion pivot around the problems we're
: trying to solve and once we have that fleshed out see if and how
: we can use hints before we realize that it's better to start
: from scratch?
The reason for that is that hints are basically working. If there's
another scheme that can work, then we can move to it, but until then
we have hints and we shouldn't be inventing hacks to get around the
fact that hints are apparently misunderstood.
I'm happy to work with you on a better scheme from scratch, but we
have to keep in mind that we need certain functionality today.
: > So if you could take a few minutes and write up a straw-man proposal
: > for what you see as doing it right, I think that would get us toward a
: > solution...
:
: As said previously in many of the emails on the subject: We need to
: seperate out the different uses or needs and come up with a layered
: solution of some sorts:
: The lowest layer is enumeration of the hardware. This, typically, is
: a combination of hardware self-enumeration, firmware-based enumeration
: or pure software-based enumeration (i.e. the proverbial hardcoded
: tables).
:
: On top of the hardware layer we have the newbus infrastructure layer
: that, given a view of the hardware provided by the hardware layer,
: constructs the newbus device tree and provides for wiring before the
: generic probe/attach sequence starts.
:
: On top of the newbus layer are the devices themselves. They use the
: newbus layer to obtain their resources and fetch device-driver
: specific settings.
:
: For the hardware layer we need a description of the hardware. The
: keying information is resource location or device path.
:
: The newbus layer needs a description of the wiring and/or routing.
: The keying information is resource location or device path.
:
: The device layer needs a description of per-instance driver options.
: The keying information is resource location or device path, combined
: with driver and unit number.
I think you are mixing layers here. The newbus layer is in charge of
assigning unit numbers. The driver shouldn't know anything at all
about device paths or resources that bind it to a unit. It is told
'probe this node and your unit number is X' and the driver has to like
it. There's a kludge in place now that I've removed in my tree for
sio so that the serial port would get the right unit number, but that
has always been considered an aberration that should be eliminated at
the first change possible.
: Concretely:
:
: A simplified hardware description could be (key=ioport):
: ioport=0x3f8 -> iosize=8, type=UART, irq=4
:
: A description for prewiring could be: (key=ioport):
: ioport=0x3f8 -> driver=sio, unit=0
:
: A description for the driver could be (key=ioport_driver+unit):
: ioport=0x3f8, driver=sio, unit=0 -> fifosize=32
:
: A serial console is defined alongside the hardware description.
: You don't define the hardware, so it shouldn't be part of it.
: You do describe intended use of the hardware, so it's should
: be in the hardware layer where you define it. As such, the
: serial console is keyed off of the ioport in the example above:
: ioport=0x3f8 -> what=console, baudrate=9600
:
: This all makes it possible to replace the sio driver with uart
: and have a different set of driver descriptions for the same
: hardware:
: ioport=0x3f8, driver=uart, unit=any, clock=1843200
I think you are mixing the levels of abstraction again. We don't want
the hardware locators to be used once the newbus bus has assigned a
unit and driver to the device. This is the main problem that I have
with this design: it blurs the line between the hardware location and
other ways of locating a device.
: You also know that competely removing the newbus information
: (i.e. the prewiring) will not affect the view of the hardware.
: It will only affect which drivers get attached and which units
: are being assigned.
:
: You also know that if the (view of the) hardware changes, your
: newbus description will match where possible and be ignored
: where appropriate. This mean that if you previously had a newbus
: description that prewires a network interface to, say, bge2 and
: you removed the interface, you simply wont use the prewiring.
: It will later be used when the interface is added back.
:
: Apply RDB theory and you can start constructing the tables.
: From the tables you can derive a more suitable way of specifying
: the information and having it used early on by a kernel.
I need more details than this. I hate to keep pressing for more
details, but I think that your view of the world leads to the same
blurring of abstraction levels that we have with hints today.
: Another thing to keep in mind is that any low-level console,
: whether serial or otherwise and whether using legacy devices
: or USB or firewire needs access to the hardware before we
: have newbus up-and running. That's why the console specification
: would be in the hardware decsription layer: you don't have
: newbus, no prewiring and no assigned devices.
If we can make consoles regular in the system, so much the better, but
we shouldn't let their needs drive the design. Consoles are a special
case today, and if they remain a special case, then I'm OK with that.
It may be the best way to cope with consoles is to have a 'console'
record that each of the possible consoles lookup. Those consoles that
match would bid for which one wins (or we support multiple ones, it
doesn't really matter to me). The matching console would then use the
value from the console key as a set of key=value pairs to give it what
it needs to do its job.
: Moving forward, we should take OFW or EFI as an example of
: how you can describe hardware and morph that into something
: that allows us to:
: o compile into some binary form for compactness
: o can be loaded as a module or specified at the
: loader prompt.
:
: Once we have that, newbus descriptions (for prewiring) are
: trivially added. Driver descriptions (or more accurately
: driver directives) should be more like var=value lines because
: of the wide and unstructured nature of what drivers may need.
So the only significant change from the current hints scheme is just
the key lookup for the device? right now the only key you can use is
the device name and unit for a given variable. Your scheme would
allow for more types of lookups than just the one key we currently
provide. Or put another way each device node in the newbus tree would
have some attributes. One would use those attributes, in addition to
the name/number to look up other attributes of the device.
I like this idea in theory. I'd like to explore ways to make it more
concrete for both the device driver interface for drivers (including
console drivers) as well as for busses that have to deal with wiring
device driver nodes in the newbus tree to unit numbers, drivers and
actual hardware.
I'll be out in the bay area in a couple of weeks. I think we're doing
some talking past each other in this email exchange. Maybe we could
get together while I'm out there and go over your ideas and see how we
can move to that kind of system. I think this might help us get the
ideas into a more concrete form than doing it just through email. Are
you up for that? If so, I can send you the dates I'm available...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080101.184909.195750479.imp>