Re: New-bus unit wiring via hints..
- From: Marcel Moolenaar <xcllnt@xxxxxxx>
- Date: Tue, 30 Oct 2007 16:20:58 -0700
On Oct 30, 2007, at 1:56 PM, John Baldwin wrote:
You rightly point out that what it really boils
down to is how devX maps to a port on the back or
front of the machine. This mapping should not
change gratuitously. Device wiring achieves that.
But on what basis will you wire things?
Correcting the mapping of device instances to physical/visible
ports will need to be based on user input. A default mapping,
based on the self-enumerating ability of hardware/firmware, may
not get it just right in all cases. But may provide a good and
reliable starting point that may end up 90+% correct.
Oof. See, here is where I think we hit a snag. :( I'm thinking in
terms of
automated installations to a wide variety of server boxes that don't
have
a GUI with a mouse and monitor hooked up so a user can clicky-clicky
to set
which serial port is sio0. :(
I don't see a snag. But maybe that's because I use
uart(4) on my machines and I have a serial consoles
no matter how things are enumerated...
So. I misread how uart's stuff works the first time, but I think I understand
now, but I think it has its own confusion. So uart_cpu_{i386,amd64} expect
there to be uart hints (wait, I thought hints were the great satan?)
Support for hints was added to i386 and amd64 to promote use
of the uart(4) driver only. The uart-way is by using the
tunable hw.uart.console and hw.uart.dbgport.
However, if you have a system with a PCI serial device or where ACPI lists the
darn things backwards then uart0 might be the PCI device, and, say, uart2
might be the device corresponding to these hints.
You're finally seeing it my way: hints are bad, m'kay :-)
The uart(4) driver then
goes and scans the hints on its own to find a set of hints that matches the
resources for uart2 and migrates the flag (and thus the serial console
setting) over to uart2, so uart2 (device at 0x3f8) does get set to the serial
console.
Yes. The only thing uart(4) uses from the hints is the I/O
address of the UART that is marked as console. Later, during
bus-enumeration we map the driver instance onto the console
like if you had no hints at all (the norm).
Instead, the
user has to know (how??) that it's /dev/ttyu2 when they setup /etc/ ttys to
have a getty listening on COM1.
Yes, /etc/ttys needs to match. This is a simple consequence of
having configuration files, like network port setup in rc.conf
and/or file systems in /etc/fstab. It's not a problem specific
to uart(4) and any attempt in uart(4) to deal with that is
wrong and futile.
That seems very non-intuitive.
It is non-intuitive. Hints are.
At least
remove the unit numbers or something and do:
uart.console.port=0x3f8
uart.console.baud=9600
Why? There's already hw.uart.console and hw.uart.dbgport that
allow you to set everything you need.
isYou've missed the point of this entirely then. :( Yes, the firmware
authoritative, and part of the goal is to fix a long-standing
weakness where
the OS is presented with two different enumerations of hardware: one
supplied
by the user via hints and one supplied by the firmware.
The "weakness" you mention is really the OSes own failure by
"presenting" itself with hardware information that has no
relation to the machine that it runs on, because it's
actually fixated by virtue of being part of the OSes source
code. It isn't supplied by the user at all. We supply it to
ourselves. Don't go blaming the user for that...
Umm, the user can adjust /boot/device.hints (I do) and can even adjust it at
boot time in the loader.
I guess OOTB means manual configuration before the kernel
boots? :-)
The idea is to trust
the firmware's notion of resources since it probably knows better
while
allowing for other non-resource information provided by the user to
be tied
to the correct piece of hardware.
Agreed...
He, that's what I said previously and you responded to with
saying that we hit a snag. I guess we don't then; or do we?
I'm confused now :-)
The snag is you want the user to explicitly set it all up whereas I require it
to be automated and reliable (_UID and ACPI namespace node names are not
reliable as per previous e-mails).
No, that's the opposite of what I want. ACPI is reliable.
Anyway, when ACPI describes the hardware, I prefer not to call the
legacy hardware ISA devices. It's important to make a clear
distinction
between enumerating and non-enumerating hardware, because that allows
you to create mechanisms for dealing with non-enumerating hardware
(i.e.
hints) without creating conflicts or ambiguity with enumerating HW.
We have convoluted this and mistakenly accepted this convolution as a
property of ISA hardware.
I've been advocating that our bus-abstraction is a good one. Devices
enumerated by ACPI can be said to be attached to an ACPI bus. At
least
it's not more wrong than saying that they are ISA devices when it's
obvious that there's no ISA bus to be found in modern hardware and
all
the legacy hardware is really on the chipsets LPC bus.
You continue to ignore that ACPI is not just a simple bus, but is a
namespace
that enumerates devices on multiple busses such as ISA/LPC, SMBus
(e.g. an
IPMI SSIF interface can be enumerated via ACPI), etc. It is much more
generic than just an ISA enumerator like PNPBIOS.
No, I don't ignore anything. I explicitly and deliberately use
the term "abstraction". It's a simplified representation of
reality. An "idea". My choice of calling ACPI a bus is probably
what confuses you. I'm fully aware that it is much more than a
bus, but it still "quacks" like one WRT legacy hardware...
So where do you hang non-ISA devices on "dumb" busses like IIC that ACPI
enumerates? Off acpi0 or the relevant parent such as iic0 or smbus0?
A device hangs off of it's corresponding bus in most cases.
The legacy devices are special in our case, because we have
1) hints that mess things up, and 2) the option of not using
ACPI, so that we do need hints to enumerate things that we
don't get enumerated any other way. Both 1) and 2) interact
with each other in that we need 1) for 2). A separate bus is
the best thing because it keeps things clear.
For uart console wiring you use I/O resources for
wiring even.
Yes, but not "even". Since bus-enumeration hasn't happened yet,
we can not describe the serial console by name+unit, because we
have no way of knowing upfront what unit number will be assigned
to the UART. The only way you can describe the serial console
is by hardware resources or by firmware-level names (such as is
the case on powerpc & sparc64).
This is why using hints to "mark" the console is wrong.
Note also that on ia64 (at least) ACPI tables exist that describe
the serial console (and debug port) and those tables use hardware
resources. So, the common denominator is I/O resources (even for
OFW-based machines) and as it is, it's really the only thing you
need (module hardware type) to make a low-level console work.
The only correct way to identify hardware for use as low-level
console is by it's location in I/O space (module hardware type).
This is what uart(4) does and it's one of the reasons uart(4)
works on all platforms even though low-level console support is
highly machine dependent. It's the right way of doing it and
as such it just works.
Do not mistake low-level console identification with bus- enumeration
device wiring or it being similar to hints.
To re-iterate:
We should reserve hints for describing non-enumerating hardware
(which means device.hints should be non-existent OOTB) and we
should add other mechanisms to wire devices to hardware, making
use of the fact that underneath it mechanisms exist to enumerate
the hardware (incl. hints for non-enumerating hardware). In the
future we can replace hints with a more flexible and expressive
means to describe hardware so that it better meets the needs of
embedded environments and without it impacting device wiring.
So what do you want: 'wire.sio.0.*?' Or do you want XML or some
binary
registery like Windows that can't be modified by the user w/o first
booting
the OS (which is real handy when it gets corrupted).
What I want is something that is appropriate. If we want to wire
hardware to devices, then we need to be able to uniquely identify
a device in hardware. A path if you will that mentions busses,
bridges devices and functions therein. Look at ACPI, EFI and OFW
for example. Such an identification is the keying entity. Data
that corresponds to that key can be complex or compound so that
you can actually specify which driver you want to use above and
beyond simply wiring it to a unit number. This also also allows
us to add other pieces of information.
I'm not going to give concrete examples, because I foresee that
the discussion will then be about how my "solution" sucks rather
than it being treated for what it is: an illustration -- something
to explain what I said and in no way complete or even usable.
Ok, what the heck. For better or for worse:
\begin{/boot/hardware.conf}
# Lines starting with '#' are comments
[pci0.0.18.0]
# First function: standard UART
# We use this for remote GDB
driver="sio"
unit=2
dbgport="9600,n,8,1"
[pci0.0.18.1]
# Second function: standard but memory-mapped UART
# doesn't work with sio(4) -- needs uart(4)
# We use this one as console.
driver="uart"
unit=3
console="115200,n,8,1"
\end{/boot/hardware.conf}
Don't get confused about marking the hardware as console
or debug port and how we do the same in hints. It isn't
the same.
Hints mark the driver instance as console or debug port.
Here I mark the *hardware* as console or debug port, even
if we don't wish to wire it to a driver instance (although
we do in the example)
Fundamentally different!
I can appreciate that, though I consider that I'm binding "sio0" to a piece of
hardware so that the other settings for sio0 are bound to the hardware and
not to the first device that the sio(4) driver decides to attach to.
I think I approach wiring from the opposite direction. It's
the hardware I'm interested in:
Fortune candidate:
A driver without hardware is meaningless, but hardware without
a driver is a source of opportunity and longing.
:-)
I
actually would like the ability to do something akin
to 'hint.pci0.18.0.0.disabled=1' to disable a PCI device.
Yes, I like that too.
(Granted, that's
still in MIB form rather than a flat file, but conceptually similar.
Agreed.
I still
prefer using the kernel env primed via a file in /boot because you can adjust
the kernel env easily in the loader.)
That definitely is a plus. At this time I don't know if we
can achieve that in the grand scheme of things, but we
should definitely not abandon it gratuitously.
Another thing to consider is that if you are going to "wire" a device to a
specific driver/unit number (so I can make COM1 always be sio0/uart0 and thus
always /dev/ttyd0|/dev/ttyu0) you need to make sure you reserve that
driver/unit combo so it can't be probed or attached by something else.
Maybe, yes. I haven't exactly ruled out a mode of operation
where the wiring is ignored if the hardware isn't there (or
is disabled) and thus that the driver instance is re-used.
Think for example about 2 similar devices (let's keep them
UARTs), one in active use and one for backup. Both are wired
to the same tty to avoid configuration changes. You can then
always use one of the two (either) knowing that the wiring
will be consistent.
I don't really know if this is a useful feature or a wave of
featuritis...
--
Marcel Moolenaar
xcllnt@xxxxxxx
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- References:
- Re: New-bus unit wiring via hints..
- From: Kevin Oberman
- Re: New-bus unit wiring via hints..
- From: John Baldwin
- Re: New-bus unit wiring via hints..
- From: Marcel Moolenaar
- Re: New-bus unit wiring via hints..
- From: John Baldwin
- Re: New-bus unit wiring via hints..
- Prev by Date: Re: Firefox Java plugin with 7.0?
- Next by Date: loader breaks with -O2 optimizations
- Previous by thread: Re: New-bus unit wiring via hints..
- Next by thread: Re: New-bus unit wiring via hints..
- Index(es):
Relevant Pages
|
