Long term compex problems from bootloader and kernel work.
Moderator: Moderator Team
-
- Posts: 1
- Joined: Mon Oct 23, 2017 5:54 am
Long term compex problems from bootloader and kernel work.
Boot loader appears from what I can tell loads all the drivers defined.
As people try building new filesystems this boot loader is going to be a trouble.
Lets try to reform the boot process a bit.
Current system requires 2 filesystem drivers for each filesystem one in the freeldr and one in the OS.
This causes problems to say the least from a development point of view.
No point developing the loader filesystem if the kernel filesystem will never work.
Lets see what can be changed in the layout.
How many and what modules and the kernel need to be loaded just to work the .sys filesystem driver. And then use this driver to access the registry and load the rest of the drivers and setup everything up.
This is faster way I hope of doing things.
The multiboot lets modules be attached to the end of the multiboot.
Ie
kernel freeloader <the commandline>
module ntoskrnl.exe
module developerfilesystem.sys
?module hal
The Internal freeloader drivers have to be using something general to interface with the filesystem.
Also this could be used to cut the size and of freeloader and depence on it.
In time it could become
kernel ntoskrnl.exe <commandline>
modules filesystem.sys
?other require modules to start reactos
The same dirty trick as linux system pull when running new filesystems.
Use a old one that the loader knows to load the parts required to start on the new filesystem.
This might be different to mircosoft but microsoft did not really want anyone less placing the thier os on top of other filesystems.
As people try building new filesystems this boot loader is going to be a trouble.
Lets try to reform the boot process a bit.
Current system requires 2 filesystem drivers for each filesystem one in the freeldr and one in the OS.
This causes problems to say the least from a development point of view.
No point developing the loader filesystem if the kernel filesystem will never work.
Lets see what can be changed in the layout.
How many and what modules and the kernel need to be loaded just to work the .sys filesystem driver. And then use this driver to access the registry and load the rest of the drivers and setup everything up.
This is faster way I hope of doing things.
The multiboot lets modules be attached to the end of the multiboot.
Ie
kernel freeloader <the commandline>
module ntoskrnl.exe
module developerfilesystem.sys
?module hal
The Internal freeloader drivers have to be using something general to interface with the filesystem.
Also this could be used to cut the size and of freeloader and depence on it.
In time it could become
kernel ntoskrnl.exe <commandline>
modules filesystem.sys
?other require modules to start reactos
The same dirty trick as linux system pull when running new filesystems.
Use a old one that the loader knows to load the parts required to start on the new filesystem.
This might be different to mircosoft but microsoft did not really want anyone less placing the thier os on top of other filesystems.
Re: Long term compex problems from bootloader and kernel wor
So, suppose you have two partitions, one formatted in FAT(16/32) in which freeldr is present (FAT is something freeldr already knows), and a second partition formatted in whatever FS you want (say, EXT4) with ReactOS installed in it.
To understand your question better, where would you place the kernel files (ntoskrnl.exe, hal.dll), and where would you place the EXT4 filesystem driver (.sys file)?
To understand your question better, where would you place the kernel files (ntoskrnl.exe, hal.dll), and where would you place the EXT4 filesystem driver (.sys file)?
Re: Long term compex problems from bootloader and kernel wor
there is nothing worse in OS development than to mimick "dirty tricks" of linux.The same dirty trick as linux system pull when running new filesystems.
it's really hard to understand what exactly you suggest.
here is the note I wanted to express still.
Filesystem implementation in the loader is not even close to the full FS implementation in kernel. Everything the loader needs is to be able to do a single threaded uniprocessor non-cached read only access to some parts of the FS instance. That's all. That's why "the problem" you've depicted doesn't exist. You just don't need a full blown FS engine inside of the loader. Even such complex FSes as NTFS have been dealt this way at the loader stage (NTLDR is able to read it). So if you want to boot your OS from 100 FSes, then yes, go and add a bit of parsing every of those 100 in your loader, you wanted it. In reality, sane OSes just use the best FSes of them and don't try to offer that moronic "feature" of booting from some Brainf&ckFS nobody will use anyway. So everything ends up in supporting a few of really needed FSes inside of the loader. No problem exists. Still, it's only about booting OS and thus where the OS resides on the secondary storage! On what FS. You are free to add 100 FS drivers for the OS to support them for a user.
Relying on some "multiboot" is a bad thing - it's a non-standard something, better align with what is a standard - UEFI. There you get FAT access for free and of course you are free to add other FS into your efi app OS loader. The same RO minimum needed.
The same applies to the Registry - yet another kind of FS, - your loader needs to understand it a little. But not more than minimum needed.
It's a normal problem of bootstrapping. Kind of a try to pick up yourself by your hands.
Oppositely, the full FS driver cannot run standalone - it relies heavily on the OS services and assumes different hardware configuration than that exists at boot time, and trying to make it to not rely on them and not assume that, will be a really messy dirty trickery not worth mentioning. let linux do that idiocy.
Re: Long term compex problems from bootloader and kernel wor
Seriously. I am no programmer.
So, I shouldn't even write on this matter.
val's advice seems valuable.
But does ARM based computer's have any UEFI/EFI? ( Beagleboard, Raspberry Pi, Wandboard )
What will happen then?
Shouldn't devs keep multiboot?
So, I shouldn't even write on this matter.
val's advice seems valuable.
But does ARM based computer's have any UEFI/EFI? ( Beagleboard, Raspberry Pi, Wandboard )
What will happen then?
Shouldn't devs keep multiboot?
Open Your Windows To Freedom
Re: Long term compex problems from bootloader and kernel wor
They don't have mutiboot either. For example Beagle boards use uboot, I believe RPi and Wandboard do too. It's a total mess capable of only booting linux.But does ARM based computer's have any UEFI/EFI? ( Beagleboard, Raspberry Pi, Wandboard )
What will happen then?
Shouldn't devs keep multiboot?
There is Tianocore Project, I heard it tries to use Beagleboard as its target, maybe somewhen UEFI implementations will get a normal thing on ARM SBCs. For example Allwinner starts to look in that direction. Personally I work in that direction too, haha. I even have some code running already. But it's a MIPS target only, yet. Finally, even uboot is kinda trying to support UEFI applications. So that your UEFI application for the OS Loader maybe could be run with it. As far as i know this way OpenBSD works with uboot - they use its revision supporting this feature and feed it their EFI loader application. On ARM boards, they support. Like Orange PIs, probably, maybe even Wandboard, don't remember right. So even now using UEFI for arm looks relevant, so much more for the future.
But is that that relevant for ReactOS? Does it run on one of those? Is there working ARM port at all? Show me it, maybe I'll try to participate.
Re: Long term compex problems from bootloader and kernel wor
No, val.
No ARM port.
By the way, a guy like you could port ReactOS to ARM, right?
It was good to see you laugh at last.
ARM MULTIBOOT-Unofficial.
Again if Freeloader is developed with UEFI/EFI then it might not boot on slightly older computers. So, I think for now stay with MULTIBOOT.
Will a BIOS bootloader boot on an UEFI device?
If yes then I see no problem in staying with MULTIBOOT.
I don't care if an ARM port exists or not. ReactOS is FOSS and so some day it will be ported to ARM.
I wish I could run ReactOS on a powerful beagleboard.
No ARM port.
By the way, a guy like you could port ReactOS to ARM, right?
It was good to see you laugh at last.
ARM MULTIBOOT-Unofficial.
Again if Freeloader is developed with UEFI/EFI then it might not boot on slightly older computers. So, I think for now stay with MULTIBOOT.
Will a BIOS bootloader boot on an UEFI device?
If yes then I see no problem in staying with MULTIBOOT.
I don't care if an ARM port exists or not. ReactOS is FOSS and so some day it will be ported to ARM.
I wish I could run ReactOS on a powerful beagleboard.
Open Your Windows To Freedom
Re: Long term compex problems from bootloader and kernel wor
There were ports for ARM, xbox and for 64 bit! I cannot find them at reactos.git, though. They have been somewhat neglected over some years now.Adcock wrote:No, val.
No ARM port.
There were once a group of university students working on the ARM port and another, anonymous group, that called themselves 'ninjas'.
Maybe someone else will post more information about these ports!
Please keep the Windows classic 9x/2000 look and feel.
The layman's guides - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
The layman's guides - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
Re: Long term compex problems from bootloader and kernel wor
A bunch of them maybe, but not just one.Adcock wrote:No, val.
No ARM port.
By the way, a guy like you could port ReactOS to ARM, right?
It's much harder to participate in a project trying to be binary compatible with NT. Than to the project that just tries to make an NT-like system.
Every function provided should behave exactly like the Windows counterpart. At both user space and kernel space, both documented and not. The same goes to a plenty of internal formats and protocols. It's way too hard to recreate all that. Especially in regard to a quite new architecture like ARM. Does anybody knows ARM specific Windows internals well? And how about drivers? There is no loads of them for ARM machines. Moreover, there is no Windows for ARM available the same way as for x86, If I understand well. You just can't buy Windows for ARM and install it on available ARM mini PCs. So far, Microsoft doesn't have such a will to open it as is for the x86 version. Only some cut and locked down "IoT" versions.
So ReactOS on ARM remains mostly unfeasible for now.
No, BIOS oriented loader will not work with UEFI machine. UEFI doesn't emulate BIOS calls the loader would want to use. For a UEFI machine, one needs to supply a UEFI OS loader for their OS. Some PCs come in a mixed mode where at the firmware configuration you could decide what mode to use - BIOS or UEFI.It was good to see you laugh at last.
ARM MULTIBOOT-Unofficial.
Again if Freeloader is developed with UEFI/EFI then it might not boot on slightly older computers. So, I think for now stay with MULTIBOOT.
Will a BIOS bootloader boot on an UEFI device?
If yes then I see no problem in staying with MULTIBOOT.
But BIOS and all those multiboot etc they are all fossils, in future, UEFI will be used as the only FW.
Of course, for ReactOS that has its main usage in old PCs, supporting BIOS is important.
The more ReactOS will be getting mature, the more chances for it to have been tried on newer machines, and thus the need to look at UEFI instead of fossils (BIOS) and surrounding crutches (multiboot).
These two sentences are contradictive a little, aren't they?I don't care if an ARM port exists or not. ReactOS is FOSS and so some day it will be ported to ARM.
I wish I could run ReactOS on a powerful beagleboard.
By the way, there is much more powerful arm boards than Beagle Boards for the same price or even less.
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: Long term compex problems from bootloader and kernel wor
I am off-topic, but I must speak up. Pointing out contradictions in what people say is abusive, and I find it offensive. I have never abused others that way and never will because I see myself as better than those who do so. I see that as being done for the same reasons that some guys commit sexual assault, and that is to dominate and control others, things that are always wrong to do to another.
Re: Long term compex problems from bootloader and kernel wor
PurpleGurl wrote: I see that as being done for the same reasons that some guys commit sexual assault, and that is to dominate and control others.
Crikey, bloody hell! - Going nuclear and equating sexual assault with anything - that's too far! That's just too feminazi. Contradictions?
I think you need to watch this and lighten up! https://www.youtube.com/watch?v=wdoGVgj1MtY
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Re: Long term compex problems from bootloader and kernel wor
What made PurpleGurl so annoyed?
Open Your Windows To Freedom
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: Long term compex problems from bootloader and kernel wor
Response moved to PM.dizt3mp3r wrote:PurpleGurl wrote: I see that as being done for the same reasons that some guys commit sexual assault, and that is to dominate and control others.
Crikey, bloody hell! - Going nuclear and equating sexual assault with anything - that's too far! That's just too feminazi. Contradictions?
I think you need to watch this and lighten up! https://www.youtube.com/watch?v=wdoGVgj1MtY
Re: Long term compex problems from bootloader and kernel wor
Not sure. She sent me a PM, I didn't read it. I'm not going to get drawn in. Regardless of what she thinks is going on, you never ever equate anything to a sexual asault! That demeans everyone and is out of order on a forum. It also reduces a sexual assault as an act that can be dismissed as inconsequential if it is only as bad as a contradiction...What made PurpleGurl so annoyed?
It annoys me that she derailed the discussion with such inappropriate words. Back on track I hope. What were you talking about?
Oh yes, ARM port - did anyone see any bad tempered contradictions? I didn't.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Re: Long term compex problems from bootloader and kernel wor
She thought I want to dominate on you. Apparently she disliked that a lot. Don't know why though. Should I try to dominate on her instead of you, or should she dominate on you instead of me... something else? Or maybe it's Halloween mood?Adcock wrote:What made PurpleGurl so annoyed?
Amazing. Your reaction is brilliant. But I am not going to play with it, trying to make jokes, I don't want to get accusations in sexual assault the second time a day! Oops, I did it, sorry. Instead, I just ask, didn't you see the smiley in the end of my question there? Wasn't it a clear sign I was asking that friendly, just as an interesting notice, without a bad intent? After all clarifications are needed if there are contradictions, just to understand what exactly one meant, that thing or the opposite thing.PurpleGurl wrote:I am off-topic, but I must speak up. Pointing out contradictions in what people say is abusive, and I find it offensive. I have never abused others that way and never will because I see myself as better than those who do so. I see that as being done for the same reasons that some guys commit sexual assault, and that is to dominate and control others, things that are always wrong to do to another.
Last edited by val on Sun Oct 29, 2017 9:22 pm, edited 1 time in total.
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: Long term compex problems from bootloader and kernel wor
I did not do that. I said that the MOTIVATIONS for doing what happened at the end (2nd to last line, similar to how someone abused me on here in the past) of what was said in the post before mine had the SAME MOTIVATIONS. Nobody equated the crime of rape, just the motivations. That demeans nobody except for those who commit the unforgivable act of trying to control others. The need to control others is why people bully, commit rape, tell others to calm down, telling others to lighten up, pointing out inconsistencies over what was said in the past (implying the person doesn't have a right to change their mind or be a different person in each moment), etc. They all are caused by the same bad motives. If you don't want to be compared to others who do other bad things with the same motives as whatever you do, then don't do those things.dizt3mp3r wrote:Not sure. She sent me a PM, I didn't read it. I'm not going to get drawn in. Regardless of what she thinks is going on, you never ever equate anything to a sexual asault! That demeans everyone and is out of order on a forum. It also reduces a sexual assault as an act that can be dismissed as inconsequential if it is only as bad as a contradiction...What made PurpleGurl so annoyed?
It annoys me that she derailed the discussion with such inappropriate words. Back on track I hope. What were you talking about?
Oh yes, ARM port - did anyone see any bad tempered contradictions? I didn't.
I sent a PM to help DEESCALATE things, but since you won't read it and feel compelled to discuss me with others, you compelled me to reply here.
Who is online
Users browsing this forum: No registered users and 46 guests