#pedigree

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

13pedigree/06develop 14aa3551a 15Matthew Iselin: posix: break early from kill() if the pid specified is a zombie

miselin/pedigree/develop (aa3551a - Matthew Iselin): The build was broken.

Build details: https://travis-ci.org/miselin/pedigree/builds/7...

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

13pedigree/06develop 144d65ccd 15Matthew Iselin: winman, libui: first pass of fixes via valgrind

silly travis

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

13pedigree/06develop 14a42b765 15Matthew Iselin: winman, libui, tui: second pass with valgrind

miselin/pedigree/develop (4d65ccd - Matthew Iselin): The build is still failing.

Build details: https://travis-ci.org/miselin/pedigree/builds/7...

Oh, Pedigree commits? :-)

miselin/pedigree/develop (a42b765 - Matthew Iselin): The build is still failing.

Build details: https://travis-ci.org/miselin/pedigree/builds/7...

kwolf: I know, crazy!

been running parts of pedigree on linux with valgrind

That sounds really useful

Just recompiled userspace programs for Linux?

That would be another advantage of using POSIX

yeah, currently recompiling userspace programs on linux

running the gui using an SDL shim

Nice

I think the last time I ran Pedigree it didn't have a working GUI yet

just have to ignore the libsdl leaks on linux ;)

heh

yeah, the gui is a huge work in progress still, but running on linux is speeding up my development

I'd guess so

it's kinda cheating, but oh well :)

I don't think so

As long as it ends up running on Pedigree, anything is allowed

Occasionally I've been doing the same. Our ext2 driver only started to work reliably when we switched to developing it and running test cases on Linux.

right

Lately I've been trying to get tyndur to work reasonably well on an old laptop. Unfortunately there is no Linux shortcut for real hardware. :-)

the tooling is substantially better on not-$youros :)

yeah that's true

my biggest problem with real hardware so far has been usb

Meanwhile I can boot that laptop from a USB stick and even use the network

AHCI CD-ROM and sound are still missing/not working

And the "just works" mode of networking is missing as well ;-)

:)

What USB controllers and devices do you (or did you try to?) support?

uhci/ohci/ehci controllers, all tested IIRC

tested on real hw that is

and devices is usb HID, mass storage, and a particular usb nic chipset (dm9601) because i had one

So pretty much everything that you could need

it's entirely possible to use pedigree with usb input devices and have the root partition on a usb drive

it's just that i need to fix bugs so the experience improves :)

With mass storage "experience improves" translates as "it doesn't eat your filesystem"? ;-)

nah, it's okay with the filesystem, but the system is still a bit shaky sometimes

it's getting better, but it's not as stable as i'd like

I know that feeling

Though I think Pedigree has always been more stable than tyndur

pedigree likes using memory though, and when it leaks it slowly gets closer to taking down the system :)

You need to run your kernel in valgrind :-)

that would be nice, and i have thought about how to do that :)

it'd require a 'linux' target where the kernel runs as a process. problem is, that never lets drivers get checked

but it could definitely test the userspace / libc / kernel interaction, with valgrind and gdb to help out

This linux target would just be another architecture?

right

That should work, but it sounds like a lot of work

it most definitely is a lot of work

this is probably why i haven't done it yet :)

i have some good ideas about how to do it, but haven't had the desire to really work on it too much

I wonder if you could somehow attach that Linux process to a qemu for the hardware part

eg, 'disk' driver which is just a disk image, plenty of use of mmap, etc

If you run qemu with the qtest machine, i.e. no real guest, it could work

miselin/pedigree/develop (b0cdd11 - Matthew Iselin): The build is still failing.

Build details: https://travis-ci.org/miselin/pedigree/builds/7...

that would be interesting

having tested a lot of this userspace stuff in linux though, i can definitely see the benefits

even if it is a lot of work

So you had to do some real porting work?

not so much for userspace, just writing some shims for pedigree stuff and stubbing out a bunch of functions to stop the linker complaining

but then, valgrind and gdb and whatever other tooling i want works now

it's tempting to do this for the kernel too :)

probably something worth starting in a git branch in any case, just to see how difficult it is

How would you do the communication between kernel and userspace programs? Would they be separate Linux processes?

they wouldn't necessarily have to be, though that would make the scheduling easier

if they were all in the one big process, then the 'scheduling' is just needing a realtime timer or something like that

but otherwise, yeah, some sort of 2-way IPC would be needed

things like virtual/physical memory get complex, moreso when sharing of that memory is needed :)

Sounds like fun

Or should I say "fun"?

definitely "fun" :)

anyway, I should go and sleep. chat to you later

Okay, good night

miselin/pedigree/develop (44e3cb5 - Matthew Iselin): The build is still failing.

Build details: https://travis-ci.org/miselin/pedigree/builds/7...