Date: Mon, 15 Sep 2008 16:05:00 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Brooks Davis <brooks@freebsd.org> Cc: freebsd-current@freebsd.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: sio => uart: one port is gone Message-ID: <A254E4A1-33EE-459F-97A0-510398BE3E8E@mac.com> In-Reply-To: <20080915222155.GD24685@lor.one-eyed-alien.net> References: <48CE59C2.9060307@icyb.net.ua> <200809151522.08679.jhb@freebsd.org> <3B9B5EED-6627-43F8-A5FC-7B2C7B2D38ED@mac.com> <200809151807.45844.jhb@freebsd.org> <20080915222155.GD24685@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 15, 2008, at 3:21 PM, Brooks Davis wrote: > 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: >>> >>> On Sep 15, 2008, at 12:22 PM, John Baldwin wrote: >>> >>>> 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 >>>> default and >>>> have the loader auto-load acpi.ko IFF the machine supports ACPI. >>> >>> Well, don't do that then. Just have the device probe check if acpi >>> is >>> supported and attach if yes. >> >> It does that, the loader stuff is from someone trying to be fancy >> and save the >> memory of not having acpi.ko around if the system doesn't support >> it. This >> may in fact be dubious. :) > > While acpi.ko is a beast (about .5MB) we're really only talking > about savings > in the case when people are using GENERIC so it seems highly dubious. I tend to agree. If we didn't had the side-effects, then it's neat little thing. It would be interesting to experiment with how we can control code/data placement, so that we can bundle code or data in a way that allows us to re-use memory when the code or data is not needed (anymore). Such as kernel initialization code, driver code, firmware data, etc... -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A254E4A1-33EE-459F-97A0-510398BE3E8E>