Re: acpivga(4) v. MI display controls
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote: The task is not trivial. On modern x86, practically *everything* that attachs has an ACPI counterpart. In a way we are thinking this backwards: the attachment should perhaps be done via ACPI that has information about the natural device tree (I recommend to boot with ACPIVERBOSE option and observe the output). This is how it is supposedly done in Windows. And consequently, *most* (MI) drivers that work on x86 need to eventually call (MD) ACPI callbacks, and vice versa. Bringing this all together in a clean (MI) implementation is hard and requires substantial changes, to say the least. As an addition, due reasons stated above, I object anything that tries to make a case for a single driver from acpi(4) -- be it acpivga(4), acpicpu(4), or the ISA and PCI cases discussed previously. This should be solved once and for all, for all acpi(4) and for all pci(4), isa(4), ... Otherwise we end up with god-awful mess. If such a solution comes to existence, we are happy to refactor acpi(4). During the ten years that ACPI has been in NetBSD, several people have tried a solution without much success. I have personally tried twice, and failed already at the self-criticism stage. - Jukka.
Re: acpivga(4) v. MI display controls
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote: This was discussed during the development process. Where? Martin
Re: acpivga(4) v. MI display controls
On Fri, Oct 15, 2010 at 10:10:18AM +0200, Martin Husemann wrote: On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote: This was discussed during the development process. Where? Already when this was first presented in 2008: http://mail-index.netbsd.org/tech-kern/2008/12/05/msg003744.html The issues noted back then are still present. - Jukka.
Re: acpivga(4) v. MI display controls
On 10/15/2010 01:50, David Young wrote: Rather than attaching new nodes at acpi0, the system should let ACPI BIOS inform the autoconfiguration process, which should attach one or more instances of a new, MI device, display(4). How would display(4) relate to wsdisplay(4) in this approach? Grégoire
kernel network interface incompatibilities between netbsd-4 and netbsd-5?
Are there known kernel network interface incompatibilities between netbsd-4 and netbsd-5? I mention this because in considering upgrading one of my servers from netbsd-4 to netbsd-5 I noticed that a static-linked arpwatch binary built on netbsd-4 was complaining about bogons on my network even though they were not bogons -- they were all in the same subnet: Oct 15 12:36:39 historically arpwatch: bogon 204.92.254.6 8:0:20:21:99:db Oct 15 12:36:48 historically last message repeated 10 times Oct 15 12:36:49 historically arpwatch: bogon 204.92.254.244 0:f:d3:0:5:83 Oct 15 12:36:50 historically arpwatch: bogon 204.92.254.6 8:0:20:21:99:db Oct 15 12:37:05 historically last message repeated 14 times I also noticed that unbound wasn't answering DNS queries ether, though it didn't make any complaints. Unfortunately the old netbsd-4 fstat is useless against a netbsd-5 kernel to see if unbound was actually listening on the right interfaces. -- Greg A. Woods +1 416 218-0098VE3TCP RoboHack wo...@robohack.ca Planix, Inc. wo...@planix.com Secrets of the Weird wo...@weird.com pgp4moR2WFLUD.pgp Description: PGP signature
Re: kernel network interface incompatibilities between netbsd-4 and netbsd-5?
On Fri, Oct 15, 2010 at 02:01:02PM -0400, Greg A. Woods wrote: Are there known kernel network interface incompatibilities between netbsd-4 and netbsd-5? A buffer overrun in the interface ioctl code was fixed, and some formerly working but technically incorrect programs that used to work stopped working when run under binary compatibility. Unfortunately, this was unavoidable unless the bounds violation was to be preserved... Thor
Re: acpivga(4) v. MI display controls
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote: On Thu, Oct 14, 2010 at 06:50:30PM -0500, David Young wrote: Rather than attaching new nodes at acpi0, the system should let ACPI BIOS inform the autoconfiguration process, which should attach one or more instances of a new, MI device, display(4). For example: vga0 at pci0 device ... function ... display0 at vga0: Ext. Monitor, head 0, bios detect (ACPI CRT1) display1 at vga0: TV, head 0, bios detect (ACPI DTV1) display2 at vga0: Unknown Output Device, head 0, bios detect (ACPI LCD) In this way, no single device has two representations in the device tree (think about the consequences, they're not pretty), and every device appears in the most appropriate place in the device tree for the purpose of suspending, resuming, detaching and re-attaching it. Jukka, This was discussed during the development process. Joerg brought a similar objection as I have, in http://mail-index.netbsd.org/tech-kern/2008/12/05/msg003747.html, but I have not found any acknowledgement or discussion. He wrote: OK, what this code is doing is essentially attach a device to the acpi tree that really refers to a PCI device. Can we please get this to attach as child of vga0 by checking for a device matching the PCI address of vga0, that also provides _DOD and _DOS. This would prevent accessing vga0 on resume before it has been reset. Joerg calls attention in that last sentence to the possibility of defects in suspend/resume that arise when a device is represented twice in the device tree. Sounds familiar. :-) Sure, the above is the ideal case. Yet once again I need to remind that we can not hold back important acpi(4) work because the perfect abstraction has not arrived, My intention was not to compare the ACPI implementation against some ideal, but to compare it with the rough consensus about what should be done, and to bring attention to real defects in the status quo. der Mouse has pointed out that NetBSD already uses the information from OpenFirmware (OF) to guide autoconfiguration of, for example, PCI devices. That's not an ideal, that's running code! :-) NetBSD should use information from ACPI similarly to OF information. and no one seems to really know how it should be done. ISTM that more than one developer can, and has, described in a broad outline how it should be done. For example, I can outline how device_register() can be used to put ACPI information into MI device properties for device-attachment hooks to read back out. I'm happy to give more detailed suggestions, too. I even have some running code for matching PCI buses and devices with information about corresponding MMIO extents derived from PCI BIOS. The task is not trivial. On modern x86, practically *everything* that attachs has an ACPI counterpart. In a way we are thinking this backwards: the attachment should perhaps be done via ACPI that has information about the natural device tree (I recommend to boot with ACPIVERBOSE option and observe the output). This is how it is supposedly done in Windows. I'm not sure I understand what you mean by the 'natural' device tree. I think you may have drawn a line between virtual and real device hierarchies and assigned ACPI to a different category than I would. Again, I'm not sure I've taken your meaning right. It's just occurred to me that it may help to form a group to discuss how BIOS information should be encoded and conveyed from MD code to MI drivers in NetBSD. By setting standards, we may help developers on every port leverage others' knowledge and work. What do you think? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
kernel module loading vs securelevel
Log Message: Make common kernel module binaries work on both sun3 and sun3x. Tested on 3/160 (on TME) and (real) 3/80. XXX: module files can be loaded only on single user? It looks kernel modules can't be loaded on multi user, i.e. if kernel securelevel is 1, unless options INSECURE is specified. i386 has options INSECURE by default so it just works, but is it intended feature? --- Izumi Tsutsui
Re: kernel module loading vs securelevel
XXX: module files can be loaded only on single user? It looks kernel modules can't be loaded on multi user, i.e. if kernel securelevel is 1, unless options INSECURE is specified. i386 has options INSECURE by default so it just works, but is it intended feature? It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? --- Izumi Tsutsui
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 11:23:29AM +0900, Izumi Tsutsui wrote: It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? Yes. Otherwise it's quite easy to defeat securelevel by causing the loading of a module that resets it to -1. -- David A. Holland dholl...@netbsd.org
Re: kernel module loading vs securelevel
It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? Yes. Otherwise it's quite easy to defeat securelevel by causing the loading of a module that resets it to -1. Hmm, what do you think about this feature? Only available in INSECURE environment? Working file: kern_module.c revision 1.26 date: 2008/11/14 23:06:45; author: ad; state: Exp; lines: +85 -3 - If the system encounters a severe memory shortage, start unloading unused kernel modules. - Try to unload any autoloaded kernel modules 10 seconds after their load was successful. --- Izumi Tsutsui
Re: kernel module loading vs securelevel
If I remember correctly, autoload bypasses the authorization calls within the module subsystem. Autoload also works ONLY for modules that are either built-in, passed by the bootloader, or located in the official directory; autoloading from the filesystem is prohibited if the pathname contains any '/'. On Sat, 16 Oct 2010, Izumi Tsutsui wrote: XXX: module files can be loaded only on single user? It looks kernel modules can't be loaded on multi user, i.e. if kernel securelevel is 1, unless options INSECURE is specified. i386 has options INSECURE by default so it just works, but is it intended feature? It would seem to be intentional. After all, kernel modules can do all sorts of nasty things if they want to. In that case, module autoload/autounload is not functional at all and we have to specify all possible necessary modules explicitly during boot time?? --- Izumi Tsutsui !DSPAM:4cb91b7e2433872420069! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
