Page 1 of 1
ee syscalls and C libraries
Posted: Thu Aug 18, 2005 2:19 pm
by whizdom
Well, I managed to create an EE syscall. I can't access the common libraries from the syscall (for a printf!) How do we access the libraries from kernel space? A printf would definitely make debugging nicer;) Also, can we call user process functions from the syscall and then return safely to the function that made the syscall?
I read the mips manual and they talk about switching stack space. I assume something to do with the sp and gp (for lib access,) but I don't know what. Someone with a clue, please clue me in :).
Thnx.
Posted: Thu Aug 18, 2005 3:47 pm
by cheriff
It comes down to how printf is handled by ps2sdk. If you follow the code for printf in libc, you find the by the time it boils to putchar is calls functions like cache flush (and sifRPC stuff? i forget..) Anyway, my point is, there are several syscalls within printf. And syscalling from within a syscall handler never is a good idea! =)
I trod down this path too, once upon a time.
The best idea i had (but never got around to trying) was something like:
Code: Select all
/* running in own thread - in user space*/
char globalbuffer[MAX];
void printf-server(){
while(1){
sleep();
printf("%s",globalbuffer);
}
}
void kprintf(char *fmt, ...){
/* Do whatever it is that teh regular printf does with vsprintf and the arglist and all the hee-ha. just get the string into globalbuffer*/
iwake_thread(print-server_tid);
}
Thats off the top of my head and probably not the proper function names, but im sure you get the idea behind it,
altho it does seem kinda strange to have a userthread working for kernelspace, but hey.
SIO would be perfect, but im not hw good enough to build a cable for that =(
Posted: Sun Aug 21, 2005 4:59 am
by whizdom
cheriff: Thant's a good idea.
A thread call should make things easier, I don't have to do the call changes and stuff by myself. However, won't the problem of multiple syscalls still exist, since there is no guarantee that our syscall has exited before the printf-thread(in yr message) starts executing and calls a syscall. Or did I get that wrong?
I was thinking in the lines of:
- save current process state in mem
- change return address to a user function that calls printf
- let the user process call printf and destroy all the state information that the kernel stores
- call back the syscall to restore state so that the execution of original function that called the syscall can continue!
(I left out some details, but hopefully you get the idea?)
Posted: Sun Aug 21, 2005 5:40 am
by dlanor
whizdom wrote:cheriff: Thant's a good idea.
A thread call should make things easier, I don't have to do the call changes and stuff by myself. However, won't the problem of multiple syscalls still exist, since there is no guarantee that our syscall has exited before the printf-thread(in yr message) starts executing and calls a syscall. Or did I get that wrong?
I think you did get it wrong, as he clearly stated that the thread doing the real printing is executing in 'user space'. In other words, that excution is not made in any syscall, so the conflict never arises.
Your mistake probably lies in thinking that the 'wakeup' call would have immediate effect, transferring control directly to the printing thread, but that is not what it should do. It should just transfer that thread into the list of threads scheduled for future execution. (Hopefully *I* got this part right... ;) )
Best regards: dlanor
Posted: Sun Aug 21, 2005 7:53 am
by TyRaNiD
The big issue as noted is that printfs require alot of work to get it to your ps2link console, this is down to the fact that you have to go via the SIF to get your data to the IOP.
Now one way you could do it would be to write a custom tty app, write the strings directly into IOP ram (using the EE mapping) and toggle a bit in a SIF reg to do mutal exclusion.
The simplest way quite frankly is to install an SIO mod if you are going to do any extensive kernel hacking, check out sioshell in that case. That does things like hooking the kernels own printf handler (yes there is a printf in there, limited but it is there), sioshell even sets up the unused kernel print syscall to point to the kernel's printf function :P. Or you could implement your own custom printf (using sprintf and sio_write).
If you install SIO you will glad you did, trust me :P
Posted: Sun Aug 21, 2005 11:55 am
by cheriff
Yeah, I pretty much got about this far and realised SIO was the way to go. Here on my desk i jave 2 max3323's and buggered if i know what to do with them now... am useless with a soldering iron.
Although the idea of having a custom iop app to talk to ps2ip and used the mapped memory to communicate seems great.
Is a shame since playing around in the low level guts would be kinda fun. And having another cable running across the floor from my ps2 would just be so l33t ;)
algorithm and memory access
Posted: Mon Aug 22, 2005 8:39 am
by whizdom
I haven't looked at sioshell yet, but, following up on cheriff's original algorithm... since my thread knowledge is not so strong, I wanted to confirm the algorithm here. Is a preliminary algo like the following ok?
Original Thread (OT)
- start printf thread (PT)
- ...
- Call our syscall
- ...
Syscall thread
- sleepthread...
- printf
- resumethread(OT)
syscall:
- do stuff...
- isuspend OT
- wakeup PT
I'm suspending the OT to ensure that PT prints before the OT continues!
Now for a memory access problem ... I don't want to pass too many parameters to my syscall and so I want to share the OT_id, PT_id with my OT, PT, and the syscall. Now, I've defined a global aligned 16 (probably no need for that?) memory variables for the ids, however, my syscall doesn't do very well with accessing them (I tried writing/reading - but the syscall freezes.)
How do I define these global variables that all my threads/syscall can share?
Thanks for all the replies.