Voix first public mess

mystran · Post by **mystran** » Sat Mar 31, 2007 10:20 am

http://www.cs.hut.fi/~tvoipio/files/voix/fd-348.img.gz is the latest image that I'd be happy if people would test a bit. (I'll keep this post up-to-date with updates)

Report anything that says "exception" or pastes lots of colorful stuff. If you manage to get it boot, there's a file which'll tell some more.

Nothing really fundamental, but I'd like to know if it crashes on anyone...

and mm... i HOPE the GRUB on the disk will boot on any i386 now....

You'll need a few megabytes of memory (I'd guess around 8 will work fine, maybe less) and mm.. it's relatively unlikely that it'll attempt to touch anything like a disk drive (hard or not), so no need to worry about that.

edit: oh and obviouosly report anything that says "panic" as well

mystran · Post by **mystran** » Sat Mar 31, 2007 11:46 am

I renamed the file to .../fd-347.img.gz since it's easier that way for me to keep track of what SVN revision it was.

Brynet-Inc · Post by **Brynet-Inc** » Sat Mar 31, 2007 12:07 pm

It looks good mystran, Works perfectly under QEMU on a OpenBSD host..

Have fun with your project...

mystran · Post by **mystran** » Sat Mar 31, 2007 12:32 pm

Did you find the egg?

mystran · Post by **mystran** » Sat Mar 31, 2007 12:39 pm

Oh and for those that wanna see some quality code, I'll post the source code for the "shell" (that is, what is loaded as 'init' currently) here.

It won't compile as such (need "libvoix.a" interface library for the system calls, and the ../fs_types.h for the kernel types) but it someone might find it interesting to study, since it's relatively simple, yet implements some interesting stuff in userspace.

And if somebody wonders, my read() and write() are non-blocking, hence the event1 calls to wait for certain types of states on the file descriptors..

And mm.. I know there's a bug in cmd_cat.

Brynet-Inc · Post by **Brynet-Inc** » Sat Mar 31, 2007 12:56 pm

Egg?.. I don't think so...

But I noticed one thing... changing into / from inside of /dev for example apparently succeeds, but the current directory remains /dev..

Maybe you just don't use the / or \ notation for paths.. ?

No clue..

But && for example could be a handy "mini-shell" feature...

Code: Select all

=>> command1 arg && command2 arg

mystran · Post by **mystran** » Sat Mar 31, 2007 1:48 pm

If you read the 'welcome' in / it'll tell you that absolute paths are still resolved as relative paths starting from current working directory, which probably explains your issue..

Try 'cat welcome' when you are in /

edit: in other words, '/' in '/dev' starts lookup from '/dev', skips the leading '/', sees that it's end of string, and succeeds.

Oh and the reason I'm not giving anyone access to full source necessary to build the thing (or user processes) yet, is that my kernel doesn't properly validate memory for string-parameters to system calls (like stat(), open() or chdir()), because I've been too lazy to write code for it, as it'll have to check buffers and figure length of the string at the same time..

mystran · Post by **mystran** » Sat Mar 31, 2007 2:03 pm

Ok, paths resolve from / properly now: http://www.cs.hut.fi/~tvoipio/files/voix/fd-348.img.gz

edit: though somebody forgot to actually update the /welcome file.. oh well

mystran · Post by **mystran** » Sat Mar 31, 2007 2:14 pm

Brynet-Inc wrote:
But && for example could be a handy "mini-shell" feature...
Code: Select all
=>> command1 arg && command2 arg

Well... basicly... yes.

Eventually.

I'll do that as soon as:

1) I have working fork() and wait()
2) I've bothered to write proper tokenization for the shell.

If you look at the minicmd.c, you'll see that it doesn't tokenize anything really, beyond the command anyway, and it duplicates finding the argument in each command that takes an argument..

Once I've got (1) and (2) done, I can also implement pipes, at which point I can do a pager as well..

But my priority now is to get real filesystems mounted, which involves writing some device code to read floppies and/or harddisks, and then some filesystem code to actually extract interesting stuff from those.