No motivation?

[Octacone]

Hey peps.

I don't know what to do. I have like zero motivation to continue working on my FAT 32 bootloader. Actually I haven't touched it in a while (3 months).
It just feels boring. Assembly is really hard to work with, you constantly have to know what each register holds. When I try to work on it, I immediately quit.
What to do? (GRUB is not an answer, please, I doesn't fit, don't ask why). I want to work on my OS, but in order to do that I have to finish that awful thing.
How do I get motivated?

[DavidCooper]

Hey peps.

I don't know what to do. I have like zero motivation to continue working on my FAT 32 bootloader. Actually I haven't touched it in a while (3 months).

There's nothing wrong with taking time out from a project (or part of a project). I have lots of half finished parts of mine because I keep switching to whichever part I feel most motivated to work on at the time, but I keep going back and doing a little bit of each every now and then, and the gradually become complete. I have a to-do list with all these chores listed on it and I score them out when they're done, and it's highly motivating to see all the scored-out parts grow in number while the parts still to be done cover less and less space.

It just feels boring.

The most boring parts are the ones where you aren't breaking new ground, but that also means you could copy what other people have already done if you're struggling with algorithms.

Assembly is really hard to work with, you constantly have to know what each register holds.

Writing the actual code is the last step in the process and it really shouldn't be that hard. Write the whole program in pseudocode first, then work out which values you might want to hold in registers for a long time within the program, and then when you write the code, write in the comments the details of which registers hold what, and when their content is no longer needed. If you're really struggling with this, use line numbers and draw a diagram of the registers on a large sheet of paper so that you can list the changes in content of each register by line number as they occur - that will make it easy for you to find out what they hold at any point in the program. I've had ideas about writing a tool for holding this information as a more dynamic comments system so that you would put the cursor in a line of code and the tool would show you what all the registers hold at that point. Perhaps that would make a more motivating project for you to take on while you're avoiding writing your bootloader, although I don't know how hard it would be to integrate it into an assembler.

When I try to work on it, I immediately quit.

That's burn-out, and the cure for it is to take a complete break and do something else. During this break, whenever you do think about your bootloader, think first about how you can change the way you work to make it more comfortable.

I want to work on my OS, but in order to do that I have to finish that awful thing.
How do I get motivated?

Get it done is pseudocode first and tackle that and the conversion to assembly instructions in small chunks just doing a little bit each time instead of trying to do it all in a short time - it's clearly become something that's so draining mentally that this is the only way to handle it. Do one little chunk of this each time, then switch to working on something else to get your mind onto something that does motivate you (such as the more innovative ideas you have that got you into OS development in the first place).

[pat]

When I try to work on it, I immediately quit. What to do? (GRUB is not an answer, please, I doesn't fit, don't ask why). I want to work on my OS, but in order to do that I have to finish that awful thing. How do I get motivated?

You could try a sort of immersion therapy. Set aside 5 minutes dedicated to your bootloader. You don't have to work on it, just focus your attention on it; review the code, previous milestones, git logs etc. When you get the urge to quit: don't. Wait it out for the full duration and let that feeling pass. Once the 5 minutes are up, stop what you're doing and go do something you enjoy for a while to sort of cleanse your palate. The important part is to not give into that sudden impulse. Next time give it a few more minutes, and work up to a reasonable amount of time that you'd feel comfortable with and still be able to make progress.

I want to work on my OS, but in order to do that I have to finish that awful thing.
How do I get motivated?

Come up with a few fun bits you'd like to see in your OS and plan out how you'd like to (start the project? continue where you left off?). Then analyze your bootloader and identify the minimum remaining mandatory features that have to be completed in order to progress towards that plan. Create a plan for those - and just those - features, and scrap any bells and whistles that you might have wanted before. Create a realistic schedule from now to the end of that list, and make sure to limit the time for each coding session and space them out a bit.

When you feel unmotivated, pull out your fun OS goals list and remind yourself that you are making progress towards reaching that point.

[iansjack]

Could you explain why "Grub is not the answer"? It seems to me that it would free you from the tedious stuff that you really don;t want to do so that you could progress with the interesting stuff. Why persist in writing your own bootloader (which I agree is a tedious process) when it's already been done.

It strikes me that there may be a deeper problem and that you may just not want to get involved with anything unfamiliar. In which case, perhaps you should review whether this is the right hobby for you.

[Brendan]

Hi,

I don't know what to do. I have like zero motivation to continue working on my FAT 32 bootloader. Actually I haven't touched it in a while (3 months).

I think this happens to everyone eventually.

Assembly is really hard to work with, you constantly have to know what each register holds.

This sounds like a "not enough commenting" problem to me. If you split things up into routines of manageable sizes (not too big) and document the inputs and outputs half the problem disappears. For example, I always do something like this:

Code: Select all

;PASM Add Area
;______________________________________________________________________________
;
;Note: The PASM uses a dodgy "0xFFFFFFFF" type to represent "unknown". After
;      initialisation this is replaced with a "not RAM, usable" type.
;
;Input
; ebp       Area type
; ebx:ecx   Area size
; edx:esi   Area address
; edi		 NUMA domain (0xFFFFFFFF for "unknown")
;
;Output
; eax		Status
;______________________________________________________________________________

The other thing I do is comment most lines. For another example:

Code: Select all

	add ecx,esi 
	adc ebx,edx                              ;ebx:ecx = address for byte after end of area
	jnc .p3                                  ;If it didn't overflow, assume it's fine
	test ecx,ecx                             ;Is EBX:ECX nonzero?
	jne .p1                                  ; yes, size was too large to be valid
	test ebx,ebx                             ;Is EBX:ECX nonzero?
	je .p3                                   ; no, was "start + size = 1 << 64"

This takes a little longer to write the code, but saves heaps of time later (when you're "desk checking", or debugging, or making changes).

How do I get motivated?

Depends on why you're not motivated. If you're burnt out, taking a break can work. If the code isn't challenging/complex enough it's usually not too hard to find a fancy new feature to add to make it more exciting. If it's too hard to maintain the code, maybe spend some time tidying it up ("refactoring"). If you're not happy with assembly, maybe consider changing to a different language. If you're a lot more motivated to do something completely different (random example: woodworking) then maybe OS development isn't the best hobby for you.


Cheers,

Brendan

[alexfru]

BootProg?
As for motivation, you may just do it. Start doing it. However, it may take several attempts and some preparation work. For example, I have some pretty crappy code in my compiler, which I don't want to touch as long as it works. And it does (modulo a few known limitations and non-critical bugs). But making improvements in it is... eww! (I'm pondering the idea of rewriting it in order to clean it up and ease further development) One of the latest improvements took me several takes (across several months) to go through the language standard to understand the minute details of something that needed to be implemented better than it was at the time (and do some experimentation with other compilers to confirm my understanding of the matter) and to go through my code, identify the relevant parts, issues, etc. Once that prep work was done and the necessary logic documented (I think it hadn't taken more than a week in total if I exclude all the time between the takes), in about 3 days I had the improvement implemented. Then there were a couple of minor follow-ups.

Large, complex and poorly understood things are intimidating. Break them down into smaller ones. List down the goals, what you already know that you'll use to achieve them, what you don't quite know yet (e.g. you've heard of feature X and that it may be relevant or helpful to your goal Y, but you aren't sufficiently familiar with X or its details). Work on the latter (study up, experiment, etc) to refine the small steps needed to achieve the goals. You may end up creating more steps: some steps will be about doing something quite specific, some steps will be about learning something. In the process of figuring out what it takes to achieve your goals you may also realize that what you want necessitates more work than you're willing to do now or in the near future. At this point you may scale down your goals and postpone some stuff until the next version of your project or until more opportune times.

Tools to help:

• some sort of todo list, a simple text file works just fine in a lot of cases
• version control (git, etc), so you can keep working versions and see changes made when stuff breaks

[Octacone]

It is nice to see so many replies.
Thanks everybody for contributing your ideas, there are some really nice ones.
I already have an online repository that I push "bigger" builds to.
Actually I used to keep a TO-DO list while I was working on my last project, but it became unrealistic quite soon.
GRUB is not ideal for me because it is too clunky, has more lines of code than my entire OS, doesn't offer me a direct real mode interface (immediate protected mode), is pain to work with (sometimes), configuration files, itself being large, offering more than I need, you need a third party tool, uses "El-Torito", hard to work with when using a HDD, not knowing where things are in memory, not the way I want it (simple), etc...
"BootProg" won't fit because it is COM/EXE only, I need a flat binary FAT 32 bootloader. (that is my current project).
From now on I will try to comment things here and there, because each time I come back I have no idea what the code does (my own code lol).
I surely felt like I was burned out, like my creativity just vanished and I indeed wanted to do something else.
There are other hobbies than this one, that I have, but they are not as feasible. Sometimes it is just exaggerating.
Sometimes I feel like there are not enough registers on x86 to work with, pushing and poping gets messy quickly.

All in all, the good thing is that I managed to motivate myself once again. The key thing was to let the sadness go and just focus without thinking about anything else.
"What does your OS look like" can sometimes cheat on you. It doesn't make you realize how much more work you have to do in order to do anything GUI.
Small goals are they key, it seems.

[Octocontrabass]

"BootProg" won't fit because it is COM/EXE only, I need a flat binary FAT 32 bootloader.

COM files are flat binary...

[DavidCooper]

Sometimes I feel like there are not enough registers on x86 to work with, pushing and poping gets messy quickly.

I keep track of what's on the stack using comments like [$1], [$2], [$3], etc. (using the dollar sign to stand for "stack") to show all the places where I've put something onto it or removed anything from it so that I can quickly find out what's on it at any point in the program, how many things are on it, and where on the stack each stacked value is. This makes it easy to use BP to access any of them without having to rearrange them via registers.

When using assembler (or programming directly in machine code), you need to come up with standard ways of working to make the task easier when there aren't enough registers. With boot code it isn't a problem as you can simply load and save values directly to/from variables at fixed memory locations, but you need to think ahead to when you're doing multitasking with most routines being re-entrant (so that different processors can run the same routines simultaneously). A standard way to do this for use within a call is to shove all the values you need to use on the stack (a stack frame) and then work with them from there, accessing them using BP with offsets, then you copy results back to wherever they're needed and remove the stack frame.

However, if all your segments line up on the same memory space (as they should), you can do away with a lot of that copying. I just point BP at the entire set of variables used by a program and I can load/save those values to/from registers as required just by using BP with the required offsets (which remain constant for each of those variables). When writing code, using the right variable is simply a matter of looking up its offset to line up on it. If the program is opened again, another set of variables is opened for that and BP points at that set instead, so the same program code can run both at the same time without conflict (and you only need to load one copy of it - most parts of most programs effectively become library routines). When you need to call a routine which requires BP to be lined up on a small set of variables within the full set away from the start, you simply push BP and line it up on that different location, make the call, then pop BP to restore it. You should make careful use of the variables within 128 bytes either side of the start location so that single-byte offsets are used most often. If you want to use a stack frame for some reason, you are still free to do that at any time. With most of your code you should do this instead of trying to hold values in registers for long lengths of time - access to the cache closest to the processor is lightning fast anyway, so you can think of all these variables in the cache as being extra registers, while their names are simply the offset values that you have to use with BP. This simplifies everything, and it's fast. It's only with inner loops of highly repetitive code that you should worry about optimising for all-out speed by maximising the gains that can be made from careful use of registers. Most of the time you should be aiming for clear, readable code which is easy to debug.

[Brendan]

Hi,

I don't know what to do. I have like zero motivation to continue working on my FAT 32 bootloader. Actually I haven't touched it in a while (3 months).

I feel like I should make an admission here... I also lost motivation; and haven't really touched my project's code since December last year (almost 4 months now).

Everything was going well, and I took a short end of year break; then in January the Spectre and Meltdown stuff got announced - it destroyed my confidence in my ability to write secure code and made me re-evaluate all my assumptions.

I still don't know what I'm doing. For example, (for meltdown) is it better to have an extremely tiny "pico-kernel" that's always mapped in all virtual address spaces that only contains things that can be safely exposed to attackers, and then implement the majority of the micro-kernel as a special process (and can/should that special "kernel process" be CPL=3)? For another example; almost all of my reasons for continuing to support 32-bit 80x86 have evaporated over time and (with security enhancements and other features) I doubt old (or small embedded) CPUs are going to be fast enough to be worth using, so I'm contemplating redesigning everything for 64-bit only (the previous "32-bit boot code, that decides what kind of kernel to starts and either starts a 32-bit or a 64-bit kernel" becomes a much simpler "64-bit boot code starts a 64-bit kernel" scenario; and a whole pile of other legacy constraints, like if the computer supports ACPI or local APIC or SSE or CPUID, can disappear too).


Cheers,

Brendan

[Antti]

so I'm contemplating redesigning everything for 64-bit only

The obvious question might be whether to jump on the UEFI bandwagon exclusively? I think 32-bit is worth supporting today but if the plan is to concentrate on the future then it might make sense. Are you really ready to discard one of your strenghts, i.e. good knowledge of legacy systems?

Does it really cost too much to keep supporting "modern" 32-bit systems?

[Brendan]

Hi,

so I'm contemplating redesigning everything for 64-bit only

The obvious question might be whether to jump on the UEFI bandwagon exclusively? I think 32-bit is worth supporting today but if the plan is to concentrate on the future then it might make sense.

There's 2 considerations here - the number of test machines I have available now, and what kind of computers will be around in 10 years time. For (real) test machines, dropping 32-bit means losing about 20 test machines (leaving me with 4); and dropping BIOS too would mean losing 2 more (leaving me with only 2 test machines).

For supporting 32-bit; for my OS (aimed at desktop/server and not embedded systems) currently the only modern 32-bit systems that might matter are thin clients, but (with software rendering) they're not going to have the performance needed to handle the graphics anyway (and what good is a thin client without graphics?). It's already not really worth the trouble (and it's only going to get worse in the future).

Are you really ready to discard one of your strenghts, i.e. good knowledge of legacy systems?

My mind doesn't work like that - if I decide that it's not worth supporting 32-bit, then I'd be discarding something that I've decided is not a strength any more.

Does it really cost too much to keep supporting "modern" 32-bit systems?

It's a slippery slope - if I support modern 32-bit then that adds about 2 years of work; and then it's only a tiny little bit of extra work to also support "slightly less modern" 32-bit (and then it's only a tiny little bit of more extra work to also support "even less modern" 32-bit, and then...).


Cheers,

Brendan

[AJ]

Hi,

I know the discussion has moved on, but I have two suggestions for the OP:

1. Make it so that your kernel entry point checks for the boot method. This stub can make sure the boot-agnostic section of your kernel then sees uniform boot data regardless of boot method. For now, this could detect GRUB and act accordingly, but you could also have a placeholder for your own bootloader. This is the approach I took and never implemented my own bootloader because GRUB just did the job I needed.

2. Get out for a bike ride. Go swimming. Take up an instrument. Have a go at amateur drama. Come back to your bootloader when you are excited about it again.

Cheers,
Adam