On Monday 15 October 2007 01:53:49 pm Marcel Moolenaar wrote:
quoted text
> > 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...

Actually, the patch removes a kludge from sio because of this (sio(4) 
currently tries to keep sio0 and sio1 "free" for non-PCI devices in the 
sio_pci attachment, but with this patch to make new-bus always honor hints, 
sio0 and sio1 never get used by a sio part on a PCI bus).

quoted text
> > 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).

Note that PCs do still have an ISA DMA controller that the fdc(4) driver uses.

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

I see ACPI as a way to enumerate devices on "dumb" busses.  For example, I 
could see ACPI enumerating devices on other non-ISA busses, like an IPMI 
controller on an I2C bus.  That's not an ACPI device now is it?

Put another way, look at openfirmware which to my understanding includes a 
device tree/namespace with properties about devices.  (I think at least some 
sparc systems use OFW info to route interrupts for example.)  We don't make 
those devices live an on OFW bus though, they live on PCI busses, sbus 
busses, etc.  ACPI to me is much more of a firmware than a bus.  There are 
some devices (PCI links, acpi_ec, batteries, etc.) that are only enumerated 
via ACPI, and so we hang them off of acpi0 for lack of a better place to put 
them, and we leave ISA PNPBIOS devices hung off of acpi0 b/c it would be a 
bit of work to move them under the isa0 device.

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

*sigh*  FreeBSD already just accepts the current configuration of PNPBIOS 
devices, and yes, I do think that FreeBSD should trust the resources coming 
from the BIOS (ACPI or PNPBIOS, even if my laptop's PNPBIOS has the wrong IRQ 
for my laptop's COM1 (but ACPI gets it right)).  However, in the case that 
COM1 doesn't have the same resources as the "sio0" hints it ends up as sio2 
rather than sio0.  In your world where unit numbers are meaningless why do 
you care if it's sio2 rather than sio0?  The bug complaints I've seen on the 
lists and in various places are all about how ACPI gets it backwards and 
confuses things.  How do propose to fix the problem of ACPI listing COM2 
before COM1 short of completely rearchitecting how we name devices and expose 
them to userland?

Besides which this is all _optional_ since users can adjust hints however they 
see fit.

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

Hmm, ok.  So are you thinking of a registry ala Windows to remember previous 
bindings?  /dev/<some uuid-ish thing but longer> (what Windows does) probably 
wouldn't be considered usable by most folks, so you'd have to make aliases, 
but then you are back to how do "wire" the aliases?  And how should the 
kernel figure out which devices are console devices?

-- 
John Baldwin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"