#pedigree

[13pedigree] 15miselin pushed 1 new commit to 06develop: 02https://github.com/miselin/pedigree/commit/94...

13pedigree/06develop 149498eb6 15Matthew Iselin: ext2: initial work at reviving the ext2 driver.

:D

this is going to be... a project

but should be worth it

Indeed

ext2 and friends have never been my strong poit

point*

and I flunked an interview question about inodes at $job

Ah. It's probably worth really comprehending Unix filesystem semantics.

indeed

something I've been meaning to get around to for ages

just finally doing it now

I kinda desire to make my own filesystem, perhaps forked from ext2. I want to have 64-bit timestamps (with nanosecond precision) and whatever good fun things I want.

ext2 is not 2038 safe for instance. :(

why nanoseconds? surely milliseconds suffice

but yes, the other things make sense

have you looked at any non-ext filesystems?

I have a bit, but not enough. I think I really should look into BSD filesystems.

miselin: Yep, of course miliseconds suffice. But the point is actually losslessness - the rest of my system uses struct timespec with 64-bit time_t, so it's really about the user can futimens(2) any timestamp and the filesystem preserves it without truncation.

fair enough

I want ext2 for interoperability, but some of its design choices were made long ago and I don't see it as the native filesystem for my OS.

right

I've been using FAT for interopability. It's a terrible filesystem, but the tooling and support for it is everywhere.

Right. I consider FAT a filesystem for read purposes only. I'm going to skip write support as the semantics just match so poorly. Instead, I'll have a `Export to FAT' feature in my UI where people can dumb down their USB mass storage sticks so they work on silly operating systems.

FAT isn't just silly OS's, it's cameras, printers, older mobile devices, etc...

but, I don't disagree with you about it being read-only

I'm not sure how I feel about mass storage filesystems. I think the user (owner) abstraction is kinda irrelevant and in the way on such devices.

It really just contains a set of files that belongs to whatever user was using the computer at the time it was inserted.

sure, and for most users, that means HFS or FAT/NTFS

anyway, you're idealistic, and i'm realistic :) this will be another one of those things I think

it's also getting late

I do consider myself somewhat realistic. I really do understand that my plans require much more effort to pull off. :)

sortie: that's fair :)

miselin: Hehe, delayed answer.

indeed, since your comment I have slept and have even commuted, now at work

miselin: Do notice how I yell a lot at stuff in #osdev, but I generally write down the flaws in third party software and upstream the patches. :)

indeed, and patching upstream is always a good thing

eg, I haven't touched netsurf in a while, but every time I do I rant and rave like crazy

sortie: btw, one thing I've done recently is to make http://docs.pedigree-project.org update after each push, which means it's always the most up-to-date source of docs

when I get around to asking if anyone wants to contribute, I can point them at the docs to learn how things work rather than having to explain the fundamentals to everyone over and over

miselin: Aw, feel free to yell at stuff publicly. :)

It's a good first step towards chance

Netsurf? I haven't looked into that, though I do get the impression perhaps I shouldn't.

miselin: Nice. Docs are already good! :D

Hopefully it'll avoid the few things that confused me when I used pedigree :)

sortie: ^ netsurf. :(

sortie: yeah, I'll end up writing a 'user guide' kind of thing as part of the docs, and link to it from the website

(I apologise in advance for the fact that that isn't wrapped to 80 columns - I thought it was for some reason)

Oh, that's no matter, I can easily reflow that myself :)

indeed

but yeah, that's netsurf

-lhubbub

Is that even a real library? :P

it's a netsurf library for HTML5 parsing

netsurf's build system fails to include the libraries it builds on the final link line for some stupid reason

so I've had to specify them...

miselin: Oh god. That build script looks like it deals with horror. :(

yeah.

I've had to do that for $job-1 as well, so I guess in a way I've stopped yelling at autoconf and things like that because they're so much better than things I've had to deal with

I generally prefer a scheme where I patch the source code of the port (by just editing it, and then generating a patch at package creation time) rather than advanced sed calls.

Yeah. Autoconf is no saint, but it's at least consistent and can be worked with.

yeah, I need to convert those into ptaches. much of that comes from working towards getting something actually building

the damned thing doesn't even build anymore because there's an incompatibility with newer yacc/flex

Ah fun

klange hasn't posted screenshots lately so I'm leaving it until I need a graphical browser screenshot again :)

He did restore his in-compositor screenshot feature recently :)

Btw. Did you see I made a wiki page with notes on all my ports?

I did

Ah fun. I was hoping it could be useful to people like you.

probably will be :)

reminds me, I should see if the apache port is still working

and replace it with nginx sometime

Mmm. I'm developing a mind set where I want to look at the source code of stuff and see if it scares me or whether I get the impression I can trust this code. I wonder if apache is fun to look at.

httpd itself is probably not *too* bad

it uses libapr (Apache Portable Runtime)

and APR is truly ungodly

That sounds worrisomely as a libnig.

*libnih

it's literally providing a stable API that wraps the OS-specific libraries

It's always exciting when people abstract OS abstractions.

(eg, Windows, POSIX, BSD, OSX, etc...)

most of the effort in porting Apache was actually porting APR :P

Yeah. A very superficial quick glance at APR does scare me a bit.

All that portability wrapper code goes into the server exposed to a hostile environment? That does not please me. :)

On the other hand, it is advertised as a patchy server.

miselin: Do you have patches or something that shows what you did to port APR? I'm curious what it needs to know about new operating systems.

the only patch I had to do for APR in the Apache tree was tell it how to build tools to run on the build host during the build

because it used the target toolchain for those

if you have POSIX compatibility, you don't need to add anything to APR

That's a big relief. It's also fun when packages use stuff like gnulib to be portable, but it fails to work on pure POSIX systems in many cases.

If you assume unknown systems are POSIX, you can very much always be portable to them without platform-specific knowledge :)

righ

t

APR is more about things like "Oh, Windows doesn't do POSIX well, so we'll wrap winsock with our well-defined and stable API."

Right, Winsock is brain damaged.

the async stuff is useful, but it's awful

Yeah, those APR patches look somewhat manageable.

they're old patches mind you, not sure if that's how I'd do it toda

y

Ah, right. Neither of us have the awesome resources of the big distributions, our ports are bound to be old versions. :)

oh, I meant they're patches that I wrote maybe 4 years ago now - so chances are I'd do things a little differently now :)

but yes, I don't think it's newest Apache either

Yeah, that also, you gradually develop more powerful tools and methods for dealing with ports.

the end goal is building ports with Pedigree, not with Linux

Mmm. That'll be fun, it will certainly test your OS.