Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Sep 2008 17:21:56 -0500
From:      Brooks Davis <brooks@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Marcel Moolenaar <xcllnt@mac.com>, Andriy Gapon <avg@icyb.net.ua>, freebsd-current@freebsd.org
Subject:   Re: sio => uart: one port is gone
Message-ID:  <20080915222155.GD24685@lor.one-eyed-alien.net>
In-Reply-To: <200809151807.45844.jhb@freebsd.org>
References:  <48CE59C2.9060307@icyb.net.ua> <200809151522.08679.jhb@freebsd.org> <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> <200809151807.45844.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--FFoLq8A0u+X9iRU8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 15, 2008 at 06:07:45PM -0400, John Baldwin wrote:
> On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote:
> >=20
> > On Sep 15, 2008, at 12:22 PM, John Baldwin wrote:
> >=20
> > > On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote:
> > >>
> > >> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote:
> > >>
> > >>> on 15/09/2008 19:41 Marcel Moolenaar said the following:
> > >>>> So, if you compile acpi(4) as a module, you must compile all
> > >>>> it's depending drivers as modules as well. Or you compile acpi
> > >>>> into the kernel...
> > >>>
> > >>> I understand the logic, but OTOH uart can work without acpi too, so
> > >>> it's not a strict dependency.
> > >>
> > >> Well, yes. That's what's causing your "problem". You compile a
> > >> kernel without acpi but with uart. As such, uart will be built
> > >> without acpi support. uart does indeed work without acpi.
> > >>
> > >> The problem is that people then load the acpi module at runtime
> > >> and expect uart to work with acpi. That's not going to fly. If
> > >> one builds uart as a module, all possible support is included
> > >> and it works as expected.
> > >>
> > >>> Also, this (acpi dependency) doesn't seem to be documented.
> > >>
> > >> It's standard behaviour.
> > >
> > > The problem is that right now we ship with acpi.ko as a module by =20
> > > default and
> > > have the loader auto-load acpi.ko IFF the machine supports ACPI.
> >=20
> > Well, don't do that then. Just have the device probe check if acpi is
> > supported and attach if yes.
>=20
> It does that, the loader stuff is from someone trying to be fancy and sav=
e the=20
> memory of not having acpi.ko around if the system doesn't support it.  Th=
is=20
> may in fact be dubious. :)

While acpi.ko is a beast (about .5MB) we're really only talking about savin=
gs
in the case when people are using GENERIC so it seems highly dubious.

-- Brooks

--FFoLq8A0u+X9iRU8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)

iD8DBQFIzuADXY6L6fI4GtQRAhHoAJ9fFvImoYKK4uIXZnYeuGyWq3tHKgCeK/W0
5/eodxxcg0vl5DMhO3CiJ1M=
=D7G0
-----END PGP SIGNATURE-----

--FFoLq8A0u+X9iRU8--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080915222155.GD24685>