Re: New-bus unit wiring via hints..

On Friday 12 October 2007 05:17:51 pm Marcel Moolenaar wrote:
> 
> On Oct 12, 2007, at 1:20 PM, John Baldwin wrote:
> 
> > On Friday 12 October 2007 03:49:28 pm Marcel Moolenaar wrote:
> >>
> >> On Oct 12, 2007, at 11:09 AM, John Baldwin wrote:
> >>
> >>> On Thursday 11 October 2007 05:59:23 pm Marcel Moolenaar wrote:
> >>>>
> >>>> On Oct 11, 2007, at 2:41 PM, John Baldwin wrote:
> >>>>
> >>>>> 2) One of the things this fixes that is visible to users is  
> >>>>> that if
> >>>>> your
> >>>>>    machine gets the COM ports backwards when using ACPI it should
> >>>>> now get
> >>>>>    them correct (COM1 as sio0) assuming your COM ports use the
> >>>>> default hints
> >>>>>    and you have the default sio hints in your /boot/device.hints
> >>>>> file.
> >>>>
> >>>> I think you just pointed out the problem of using hints to wire
> >>>> down unit numbers, because hints will stop hinting and will start
> >>>> dictating. If I swap the serial ports in the BIOS then surely
> >>>> my hints will be wrong and ACPI will be right. A default hints
> >>>> file will be even more disastrous than before.
> >>>
> >>> hints have always dictated.  The issue is that hints are
> >>> enumerating devices
> >>> that ACPI/PNPBIOS also dictate, so how does one resolve the
> >>> differences (do
> >>> you ignore one or the other, or attempt to merge them, etc.).  Note
> >>> that
> >>> hints can always be removed.
> >>
> >> I think the conflict is resolved by having hints only apply to the  
> >> isa
> >> bus proper and stop tying apci to the isa bus. This also exposes  
> >> other
> >> flaws with hints, such as using flags to mark a device as (potential)
> >> console.
> >
> > The issue here is that the 16550 UART that ACPI enumerates is on  
> > the LPC bus,
> > that is, it's an ISA device.
> 
> LPC mimics or replaces ISA. I don't treat them the same. For one, ISA
> has actual slots to plug in extension cards. LPC is enumerated. ISA
> isn't.

Do you think we should scrap the PCI bus driver we have and make a PCI-e bus 
driver because PCI-e just mimics or replaces PCI?

> >   In this case, ACPI is subsuming the role of the
> > PNPBIOS to enumerate ISA devices.
> 
> This is a PC notion. There's no PNPBIOS on ia64 for example. There is
> ACPI that enumerates devices on the LPC bus though.

This is in the spec.  Check the introduction on page 1 of the ACPI 3.0a 
specification.  It is a "configuration interface", not a bus specification.
As far as ia64, just don't include hints for sio0 on ia64.  Shoot, ia64 uses 
uart(4) rather than sio(4) anyway, right?  On the "PC" architectures, COM1 
and COM2 are a de-facto standard, so on those platforms it makes sense to 
have sio0 and sio1 hints.  This patch does not _mandate_ hints at all.  
However, while ia64 may be able to count on having all its devices nicely 
enumerated for it one way or another, the x86 platform does not. :(

You also ignore that other platforms like arm use hints to enumerate devices 
on "dumb" busses.

> >   If you want to move all the
> > ACPI-enumerated ISA devices under isa0 (which we can do, similar to  
> > how the
> > ACPI pci(4) driver "claims" the ACPI handles for PCI devices in the  
> > ACPI
> > namespace) we can do that, but that doesn't solve the problem at all.
> 
> Hell no. That's exactly what I don't want. The isa(4) bus with its
> devices should be obsoleted entirely.

Just because there isn't a slot doesn't mean it isn't there.  If a future 
system only has PCI devices in embedded chips and only has PCI-e slots does 
that mean we need to throw out the pci(4) bus driver or force the embedded 
PCI devices to live under a different driver?

> >>> FWIW, the resources for COM1 and COM2 are largely fixed in  
> >>> practice on
> >>> existing x86 hardware which is what this would affect, and hints
> >>> can always
> >>> be removed.  Given the number of complaints from people where ACPI
> >>> enumerates
> >>> COM2 before COM1 (and the fact that ACPI made _UID useless by not
> >>> giving it a
> >>> more strict format.. it's optional and on some systems it is 0-
> >>> based while on
> >>> others it is 1-based.
> >>
> >> But aren't the complaints the immediate result of having hints in the
> >> first
> >> place. Remove the hints and the complaints go away, right?
> >
> > No.  The kernel console switches because it is bound via hints.
> 
> More hints, more problems. As I said before: it's a mistake to use
> hints for that because it makes hints ambiguous.

I disagree.  I don't really see how this makes hints ambiguous.  If anything, 
it makes them _less_ ambiguous.  Previously you would have hints for a sio0 
at resource X and a sio device at resource Y used some of the sio0 hints if 
sio0 was probed via ACPI.  At work we actually disable the ACPI attachment 
for sio and always attach it via isa precisely due to this conflict.  With 
this change, hints now always mean something as opposed to meaning different 
things on x86 depending on whether or not ACPI is used.

> >   Besides,
> > people also don't like the cosmetics of having ttyd0 being COM2 and  
> > ttyd1
> > being COM1, etc.
> 
> More legacy PC fixation. If the BIOS claims that COM1 is at 0x2f8 then
> so be it. If COM2 is enumerated first and it ends up as uart0 then so be
> it. There's no bug. It's all in a name. Device wiring would allow people
> to tie COM2 to uart1 if they want to, but all this COM-stuff is really
> nothing more than a fixation on 20-year old conventions that the rest
> of the world abandoned many years ago. It's turned into a bigger problem
> than it really is, mostly because we still have those stupid hints that
> are based on 20-year old conventions.
> 
> ACPI describes the hardware and FreeBSD should respect that. I consider
> it mere coincidence that there's a serial port at I/O port 0x3f8 that
> ends up as sio0 on most current PCs. If ACPI describes a different
> hardware configuration then I don't think that we're in any position to
> claim that ACPI is wrong or the hardware broken. We can only claim that
> IFF there's no hardware at those resources or the hardware is in fact
> non-functioning.

Sadly, this ignores the fact that much of the PC "standard" is de-facto, not a 
written standard.  Having COM1 (or serial A or however it's labeled on the 
case) being at 0x3f8 with an IRQ 4 is a de-facto standard.  Note how our boot 
code hardcodes the I/O port address for the serial console 
(BOOT_COMCONSOLE_PORT).  At work we have a lot of different machines from 
many different vendors and having that hardcoded as the default has worked 
fine.  It truly is a de-facto standard for the PC, just as having the 
keyboard at 0x60, the PICs at 0x20 and 0xa0, etc.

> >>>   I've also seen pci link devices where the _UID is the
> >>> link index from the $PIR table which == the register offset in
> >>> config space
> >>> on the PCI-ISA bridge of the controlling register) and the fact
> >>> that COM1 and
> >>> COM2 have de-facto fixed resources on x86, I think it's ok for x86
> >>> to include
> >>> default hints for sio0 and sio1.
> >>
> >> If the hints would be specific to the ISA bus, then it would
> >> definitely be
> >> ok to have them. Even though we don't support i386 hardware, it
> >> should not
> >> be a big deal to keep the support for the ISA bus. We should  
> >> really stop
> >> using acpi as an alias for isa and start treating it as a separate
> >> "bus".
> >
> > See above.  ACPI != bus.  ACPI == namespace that spans multiple  
> > busses.  This
> > is an important distinction.
> 
> Drivers need a bus attachment to work with ACPI, so we have abstracted
> it as a bus. Therefore, it's a bus in FreeBSD. The abstraction is good.
> I don't see a problem with it...

We do have to have a bus because not all devices it enumerates are LPC devices 
(and it isn't even consistent in that sometimes the embedded controller and 
PCI link devices are under _SB_ and sometimes they are under the LPC bus), 
and I actually don't mind the arrangement we have now (moving ISA devices 
around was a suggestion above to try and satisfy your requirements, I think 
it's more headache than its worth).  However, ACPI is not just a simple bus 
spec, it is a configuration interface that includes a namespace that spans 
lots of busses.  One of its stated tasks (again, see the introduction on page 
1 of the ACPI spec) is to help fill in the holes in the hacked-up PC/x86 
platform by trying to subsume lots of different one-offs ($PIR, MPTable, 
PNPBIOS, APM, etc.) into one interface.

> > If you want the configuration file separate from the kernel, then  
> > what do you
> > consider /boot/device.hints to be?
> 
> Non-existent.

Ok, let's try this again.  You said you want a configuration file separate 
from the kernel.  We have one now in the form of /boot/device.hints.  It sets 
a configuration in the form of environment variables that can be easily 
manipulated from the loader and that is independent of the kernel, but is 
instead a description of a machine.  We already set lots of other things via 
environment variables to configure the kernel as well (loader tunables like 
kern.maxfiles, etc.), so it seems rather consistent to use environment 
variables for configuring the device support that the kernel can't auto-learn 
from the hardware/firmware.  What do you want different?  Do you want it in 
XML?  Do you want it not maintainable from the loader?

-- 
John Baldwin