Presentation on hobby OS development

[xenos]

I was recently asked to give a lecture in a workshop on operating system development and low level programming, and I thought maybe someone would be interested in the slides:

"How to start writing a hobby operating system"

(If you know the wiki well, there is probably not much new for you.)

[glauxosdever]

Hi,

I was recently asked to give a lecture in a workshop on operating system development and low level programming, and I thought maybe someone would be interested in the slides:

"How to start writing a hobby operating system"

(If you know the wiki well, there is probably not much new for you.)

It's always good for OSDev to get some exposure. But please permit me to disagree about autotools. I don't think autotools avoids code duplication. On the other side, it generates a lot of code that does useless checks (e.g. the whole thing of "checking for something that's supposed to be there anyway"), which is executed again similarly when another configure script is encountered. I think our best bet still is make, possibly together with a custom configure script (i.e. not one that's automatically generated). But still, let's not use configure when we can avoid it (I think the entire Sortix, which BTW you mention as a "successful" one, doesn't use any configure scripts -- Sortix libz does though).


Regards,
glauxosdever

[Korona]

I really like meson. In contrast to autotools there is no useless boilerplate involved to make things (like proper header dependency handling) just work. (And, of course, xbstrap on a meta level to build the ports .)

I like the scope of the slides and that it discusses alternatives instead of trying to present a single best solution for each tool.

[xenos]

But please permit me to disagree about autotools. I don't think autotools avoids code duplication.

I think this is simply a matter of how these tools are used. My personal experience working on a project with multiple target architectures and compile time configuration choices it really helps a lot (select correct cross compiler, select which files to build and with which options, set #define constants in some config.h etc.) and thus spares me from writing anything these things by hand. Of course, one can achieve this also be using just make and maybe a handwritten configure script, but I would assume that this is more work / required writing than by using a ready-made tool. Of course it does many checks that I would not write if I were to do this by hand, but some of them still seem to be useful tests to check the sanity of the build environment.

I have not used meson so far. Looks quite interesting, also because it explicitly mentions bare metal targets.

Indeed, I think that the "best solution" always depends on the particular problem.

[Antti]

When it comes to the lecture, this autotools discussion sounds like a very minor detail. The overall tone of the lecture was objective and different alternatives were introduced. When developers get more experience, build tool related decisions will be resolved on the way. For example, I would not recommend my "Not-Invented-Here"-driven way where almost all tools except a compiler are rewritten (with limited functionality, of course), e.g. ISO images, FAT images, linker, mcopy, patch and zip.

One of the first things I noticed several years ago in the NOS project was the interesting usage of autotools in this kind of project. It kind of made the OS project look like a "standard" source code package and I'm saying this in a highly positive way. As far as a general lecture is concerned, this kind of approach is definitely the safest and "neutral" recommendation (although it was still represented as a way how it could be done). People may argue about autotools' merits but it has much less "opinion and taste" attached to it. Handwritten Makefiles are exactly the opposite.

Thank you for sharing the presentation! Is there something wrong with the PDF file? At least some reader programs cannot open it.

[xenos]

Is there something wrong with the PDF file? At least some reader programs cannot open it.

Hm... I did have some problems with opening my presentations before (created on Ubuntu in LaTeX with the "beamer" class, worked fine in readers on the same machine, failed to open in Acrobat Reader on Windows), but I could not figure out the systematics behind it, i.e., what might be wrong with the generated PDF and why some programs stumble. With which readers did you encounter problems, and was there any helpful error message?

[Antti]

Code: Select all

     There was an error processing a page. There was a problem reading this document (131).

My Windows computer has Adobe Reader 10.1.6 (probably very old!) but I tried it on another computer that should have a recent Adobe Reader version and it did not work either but I cannot check the version of that now.

[xenos]

Looks like this problem - I'll try to investigate it further (but have no Windows or Acrobat for testing):

http://tex.stackexchange.com/questions/ ... flatex-doc

[Solar]

I have a rather large LaTeX-borne PDF with lots of embedded vector imagery, which turns out quite a bit larger than comfortable. As a postprocessing step, I let Ghostscript work it over to bring everything to 300dpi and PDF 1.4 compatibility (reducing the file size in the process):

Code: Select all

gs -r300 -dNOPAUSE -dBATCH -dDEVICE=pdfwrite -dCompatibilityLevel=1.4 -sOutputFile=outfile.pdf infile.pdf

Give it a try, and if it helps with your issue, I might write it up as an answer for that SO question as well.

[xenos]

Interesting - I tried this command on two computers and got two different error messages

gs version 8.70:

Code: Select all

-dvar=name requires name=null, true, or false

gs version 9.26:

Code: Select all

Invalid value for option -dDEVICE=pdfwrite, use -sNAME= to define string constants

So I tried this instead:

Code: Select all

gs -r300 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sCompatibilityLevel=1.4 -sOutputFile=osworkshop_ps.pdf osworkshop.pdf

and then both give me the same error:

Code: Select all

Unrecoverable error: typecheck in .putdeviceprops

[Solar]

Geeeez... please excuse the typo. (I don't have access to the Makefile in question on my office PC, just my mobile, because the office firewalls SVN -- and I got sloppy in the transfer.)

It's:

Code: Select all

gs -r300 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -sOutputFile=outfile.pdf infile.pdf

DEVICE=pdfwrite is a string (-s), that was my error. CompatibilityLevel=1.4 is a number (-d), that was yours.

These old Unix commands are insanely powerful, and insanely unhelpful if not invoked correctly...

[xenos]

Thanks for the correction, that worked (in the sense that it converted without error message) Here is the processed file:

"How to start writing a hobby operating system"

The file size has actually increased (from 199kB to 366kB). On Ubuntu / xpdf it works just as it did before, but maybe someone who has Windows and Acrobat may give it a try as well.

[coderTrevor]

Nice presentation! The latest version worked for me in Windows in Acrobat reader.