Re: BIOS call fallback

>The OpenBSD process is quite well understood. Use the best methods, >doubt what you do, refractor. Simple in concept, but it takes a lot >of time. >Therefore I am looking forward to seeing what you and James can do. >How long do you think it will take you? Can we expect to see working >code

Re: BIOS call fallback

> >The OpenBSD process is quite well understood. Use the best methods, > >doubt what you do, refractor. Simple in concept, but it takes a lot > >of time. > > >Therefore I am looking forward to seeing what you and James can do. > > >How long do you think it will take you? Can we expect to see

Re: BIOS call fallback

Oh, don't get me wrong - that was just an idle thinking out loud "what if?" Rather than a serious proposal. On 22 Dec 2015 2:05 am, "Theo de Raadt" wrote: > > > To be fair, i'd love to see the OpenBSD approach to software development > > applied to BIOS/EFI firmware. > >

Re: BIOS call fallback

>I guess in the absence of a seriously thought out wish list such a project could be open ended. >The more care spent in hardware design choices I guess the more likely we could avoid the mess >that various legacies have caused. Here's a suggestion for a community that is base around the claim of

Re: BIOS call fallback

On Tue, Dec 22, 2015 at 11:19:01AM +, Read, James C wrote: I guess in the absence of a seriously thought out wish list such a project could be open ended. >The more care spent in hardware design choices I guess the more likely we could avoid the mess >that various legacies have caused.

Re: BIOS call fallback

On Tue, Dec 22, 2015 at 11:19:01AM +, Read, James C wrote: I guess in the absence of a seriously thought out wish list such a project could be open ended. >The more care spent in hardware design choices I guess the more likely we could avoid the mess >that various legacies have caused.

Re: BIOS call fallback

Read, James C wrote: > >Also, BIOS functions are traditionally coded only powerful enough bootup > style operation. > > I'm not sure what you mean by 'powerful enough'. Somebody who installs OpenBSD > and cannot access the internet now has a double problem 1) he can't access the > internet 2) he

Re: BIOS call fallback

> Well there you go. Get to it. See you in 10 years. Seriously, though. The thought must have crossed your mind at least once during all these years of mopping up the mess that MS/Intel seem to have concocted over the years. I wonder what a hardware system designed by BSD bootloader, kernel

Re: BIOS call fallback

> Seriously, though. The thought must have crossed your mind at least once > during all these years of mopping up the mess that MS/Intel seem to have > concocted over the years. > > I wonder what a hardware system designed by BSD bootloader, kernel and driver > hackers would look like. I should

Re: BIOS call fallback

To be fair, i'd love to see the OpenBSD approach to software development applied to BIOS/EFI firmware. For a start, it wouldn't have the nightmare that is Intel AMT sitting below the OS and offering a massive security hole. On Tue, Dec 22, 2015 at 1:36 AM, Theo de Raadt

Re: BIOS call fallback

On Mon, 21 Dec 2015 23:41:18 + "Read, James C" wrote: > > Well there you go. Get to it. See you in 10 years. > > Seriously, though. The thought must have crossed your mind at least > once during all these years of mopping up the mess that MS/Intel seem > to have

Re: BIOS call fallback

> To be fair, i'd love to see the OpenBSD approach to software development > applied to BIOS/EFI firmware. > > For a start, it wouldn't have the nightmare that is Intel AMT sitting below > the OS and offering a massive security hole. Gareth, The OpenBSD process is quite well understood. Use

Re: BIOS call fallback

>Because the kernel cannot know what memory it should leave untouched, >to use such BIOS functions. Why not? I understand that there is some degree of variance amongst BIOS usage of memory but the upper bounds seem to be clearly defined (if I am not misinformed). And surely it would be possible

Re: BIOS call fallback

> >Because the kernel cannot know what memory it should leave untouched, > >to use such BIOS functions. > > Why not? I understand that there is some degree of variance amongst BIOS > uaage of memory but the upper bounds seem to be clearly defined (if I am not > misinformed). And surely it would

Re: BIOS call fallback

On Mon, Dec 21, 2015 at 11:19 AM, Read, James C wrote: > I'm not sure what you mean by 'powerful enough'. Somebody who installs OpenBSD > and cannot access the internet now has a double problem 1) he can't access the > internet 2) he therefore can't search online for

Re: BIOS call fallback

On Mon, Dec 21, 2015 at 04:19:38PM +, Read, James C wrote: The more I look into this the more I start to think that I wasn't being extreme enough when I decided it would be easier to build my OS than play around with everyone else's. It now seems what I should have decided was to build my

Re: BIOS call fallback

> Somebody who installs OpenBSD and cannot access the internet now has a > double problem 1) he can't access the internet 2) he therefore can't > search online for information about how to fix the problem. IF you're installing a new and unknown OS on your only Internet-capable device - you are

Re: BIOS call fallback

> Given that most OS mailing lists/forums seem to be dominated with hardware > problems my basic question is does OpenBSD have a fallback option to just use > BIOS routines to get hardware working if even slower than feasible but at > least working? No. > And if not why not? Because the kernel