From mboxrd@z Thu Jan 1 00:00:00 1970 References: From: Steve Simon Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <35766389-472D-49CB-A992-487EA74C86E9@quintile.net> Date: Sat, 19 Nov 2016 18:42:52 +0000 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [9fans] Plan 9 5th Edition Topicbox-Message-UUID: ac7b02f8-ead9-11e9-9d60-3106f5b1d025 Cinap, I salute you and the good sense you write. -Steve > On 19 Nov 2016, at 16:57, cinap_lenrek@felloff.net wrote: > > calling into firmware code is a big can of worms because firmware is full > of bugs and only works with a small set of the major operating systems that > the firmware authors tested it with. > > and theres not really an option for doing it from userspace. > > you need to call it from kernel mode ring zero and make sure the firmware > has the same idea of the virtual memory mappings as your kernel plus > work arround the unstated assumptions of the firmware. > > linux has a track record of bricked machines and firmware corrupting > memory. > > it is just not worth it. > > in 9front, the kernel never calls firmware. it does interpret a limited > set of acpi methods on boot to figure out pci interrupt mappings and > and then frees the acpi environment never to return. > > all efi/bios calls are done by the bootloader *before* it enters the kernel > so we never have to rely on efi/bios firmware assumptoins. the bootloader > collects the information from efi and passes it to the kernel as plan9.ini > variables. > > efi firmware has a boot manager were the user can add and modify entries. > > -- > cinap