Re: New-bus unit wiring via hints..

On Oct 15, 2007, at 9:16 AM, John Baldwin wrote:

>> 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?

Oh, come on...

>>>   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?

Yes. The intend is to use uart(8) by default on i386 & amd64 as well.

>   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.

It depends. See below.

>   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. :(

It makes sense to provide for a way to deal with the fact that on
i386 ACPI may not be enabled. Hints would do that, yes. However,
this implies that if ACPI is enabled, hints should not take effect.

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

Using hints for embedded busses is really just a hack. We need to
have a device tree for those if we want to handle all aspects of
device configuration and enumeration. The use of global unit numbers
in hints make hints flawed by design and unusable when hinted
devices exist on other busses as well. Since this typically happens
for serial ports, it's not at all surprising that this discussion
focusses on serial ports...

> 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?

You're analogy makes no sense. For one you argue that ACPI is not
even a bus and secondly if we would have embedded devices based on
the ISA bus signalling definition then obviously we would still
use the ISA bus (for need of a DMA controller).

I see ACPI (abstractly) as providing for an enumerated ISA bus.
As such, you either use ACPI or not. If not, you need somthing
like hints. Using both hints and ACPI at the same time is just
bad.

Implementing device wiring using hints is not only partial it's
also encumbered and ambiguous.

>>> 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.

It's interesting to see how you defend hints when it's so obvious
that they are a source for problems. I think the "solution" to
disable ACPI is a good indication of why you want to retain hints.
Even though it's the opposite of forward progress.

At least now I understand why you opted to use hints for device
wiring :-)

>>>   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.

No, it doesn't ignore anything. The question is whether we want
freeBSD to run with the PnP OS setting in the BIOS enabled or not.
If yes, then you have to let go...

>>> 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.

I said:
  "I would rather see us go in the direction of having the kernel
maintain a configuration file."

/boot/device.hints is not maintained by the kernel.

I don't feel a desire to argue any longer about this. My thoughts
are mostly academic at this point in time and hints are still here
(unortunately). If you think it is a good thing than by all means
commit. I only ask if you can make it optional.

Thanks,

-- 
Marcel Moolenaar
xcllnt_at_mac.com