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. >>>>> You've missed the point of this entirely then. :( Yes, the >>>>> firmware >>> is >>> 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_at_mac.comReceived on Tue Oct 30 2007 - 22:21:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:20 UTC