Re: puc(4) man page update?
- From: Marcel Moolenaar <xcllnt@xxxxxxx>
- Date: Fri, 04 Jul 2008 16:11:20 -0700
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.
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".
--
Marcel Moolenaar
xcllnt@xxxxxxx
_______________________________________________
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: John Baldwin
- 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
- Re: puc(4) man page update?
- From: John Baldwin
- puc(4) man page update?
- Prev by Date: Re: puc(4) man page update?
- Next by Date: Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
- Previous by thread: Re: puc(4) man page update?
- Next by thread: Re: puc(4) man page update?
- Index(es):
Relevant Pages
|