Re: puc(4) man page update?
- From: John Baldwin <jhb@xxxxxxxxxxx>
- Date: Fri, 4 Jul 2008 21:08:25 -0400
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
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: puc(4) man page update?
- From: Marcel Moolenaar
- Re: puc(4) man page update?
- References:
- puc(4) man page update?
- From: Alexey Shuvaev
- Re: puc(4) man page update?
- From: John Baldwin
- Re: puc(4) man page update?
- From: Marcel Moolenaar
- puc(4) man page update?
- Prev by Date: Re: may I commit this small umodem patch ?
- Next by Date: Re: may I commit this small umodem patch ?
- Previous by thread: Re: puc(4) man page update?
- Next by thread: Re: puc(4) man page update?
- Index(es):
Relevant Pages
|
