Re: puc(4) man page update?

On Friday 04 July 2008 07:11:20 pm Marcel Moolenaar wrote:
> 
> On Jul 4, 2008, at 3:32 PM, John Baldwin wrote:
> 
> > On Friday 04 July 2008 06:06:48 pm Marcel Moolenaar wrote:
> >>
> >> On Jul 4, 2008, at 2:33 PM, John Baldwin wrote:
> >>
> >>> On Friday 04 July 2008 03:31:41 pm Marcel Moolenaar wrote:
> >>>>
> >>>> On Jul 4, 2008, at 2:59 AM, Dmitry Morozovsky wrote:
> >>>>
> >>>>> doesn't splitting uart out of kernel broke serial console? Last  
> >>>>> time
> >>>>> I checked
> >>>>> it did.
> >>>>
> >>>> Yes, it does. The serial console is setup/initialized and
> >>>> used before pre-loaded modules are linked and/or usable.
> >>>> We don't have the support in place that allows you to boot
> >>>> without console until pre-loaded modules are initialized,
> >>>> at which time add a low-level console device is setup.
> >>>> It's not that hard to do, I think.
> >>>>
> >>>> So, currently low-level console drivers, such as dcons(4),
> >>>> sio(4) and uart(4) need to be compiled into the kernel.
> >>>> Consequently any devices/busses to which any of these can
> >>>> attach must be compiled into the kernel as well. Of these
> >>>> acpi(4) and puc(4) are good examples. acpi(4) is a good
> >>>> example because we use hints to work around the issue and
> >>>> have sio(4) attach to isa(4) instead...
> >>>
> >>> Actually, sio does attach to acpi0.  What happens for sio is that  
> >>> the
> >>> low-level console stuff is just doing bare-bones inb/outb anyway.
> >>> sioX
> >>> devices do attach to acpi0 though just fine.
> >>
> >> That's because sio(4) compiles-in the acpi bus attachment
> >> even if acpi is not compiled-in. That's cheating :-)
> >
> > No, that's how new-bus works. :)  It's perfectly fine to do that.
> 
> In general, yes. How sio(4) does it, no. sio(4) tied acpi(4)
> with isa(4) so that if you get the acpi(4) bus attachment
> when you have isa(4) compiled-in. Consequently, you lose
> acpi(4) support if you build a kernel without isa(4) support.
> You also accidentally avoid the problems of having acpi(4)
> as module.
> 
> It's a kluge. On ia64 we need acpi(4) but we can't have isa(4),
> so it's not a generic solution at all.

This is rather minor and easily fixable (< 5 minutes).  You could just copy 
sio_isa.c to sio_acpi.c.

> > The
> > attachments get bound at runtime.  This is actually an important  
> > feature.
>
> It's an important feature of KOBJ, yes. The point of compiling
> drivers into the kernel is to get just what you need. Not a
> bunch of bus attachments you don't want. Modules have pretty
> much all bus attachments because they need to work with
> whatever kernel they're loaded in.
> 
> So, sio(4) is not following the rules in the strictest sense.
> That's why sio(4) is a bad example, why the problem is not
> adequately acknowledged and people keep running into the same
> old problems of things not working "as expected".

This is because acpi is a module.  One way this could be fixed is to not put 
ISA devices enumerated by ACPI on acpi0, but instead of an ACPI-aware ISA bus 
driver for devices on ISA/LPC that ACPI enumerates.  You don't like that idea 
even though it is probably the cleanest solution.  Also, none of that will 
fix any of the actual problems people have (i.e. COM1 being sio1 and COM2 
being sio0 because the BIOS lists them backwards.  This happens to work in 
the non-ACPI case with PNPBIOS due to far grosser hacks that cause PNPBIOS 
devices to not even be used if hints are present.)

-- 
John Baldwin