New gs stuff in ps2lib
New gs stuff in ps2lib
Why is this going into libkernel?
I don't see why another library should be spawned for simple, hardware access functions. Its not like I put a 3ds loader into libkernel, I just felt it could use a few control functions and perhaps a little more abstraction rather than have each part (graph.c for example) carry its own little toolbox of dma/gs/etc routines.
-
blackdroid
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
Perhaps now would be a good time to actually state what the purposes of each part of ps2lib are. What exactly is a libkernel? Should we have a libsif, libsyscall, libwhatever? Where is the line drawn? The only time I get information like this from you folk is after I've actually done it.
In any event my brief stint with code contribution has met with the standard ps2dev resistance. I'll go back to doing my own codebase now. Sorry for the trouble.
In any event my brief stint with code contribution has met with the standard ps2dev resistance. I'll go back to doing my own codebase now. Sorry for the trouble.
graph.c is legacy stuff that I hate having in libkernel. Matter of fact there's some comment from me saying "this stuff needs to go" or something in kernel.h. Snatching it out at this point would break a ton of stuff using it. Granted, it's not so difficult to add another -llib to the link step, but if you want to talk about ps2dev resistance, you should've seen the jump to ps2lib 2.0, even though there is a compat.h header for all of the renamed functions. :P
The argument is not for old stuff that is painful to change. If you're submitting something new I don't see what's the big deal with splitting it out now, esp. since you've just added it and so no one else has used it yet.
As far as the other stuff in libkernel, SIF stuff was there before I started dealing with it and IIRC no one felt it had to change into it's own lib. libc stuff we also came to a consensus after a back and forth over how to do it (check the ps2dev/ps2cvs ML archives, it should be there). There's a history behind the libc stuff even before mine made it into ps2lib, because there used to be a mini-libc in ps2lib that was gutted in favor of newlib. Once folks saw newlib was crap the consensus was to move libc back into ps2lib, and libkernel was the chosen library because: a) it is always linked to the application (if you're using ps2lib, of course), b) libc depends on libkernel, and c) we didn't expect to need/use all of libc, just a few "necessary" functions. Besides SIF and libc, all that remains in libkernel is syscalls and other glue code which does actually belong in libkernel.
TBH, I wouldn't be opposed to splitting out libc, considering that it has grown way beyond just a few "necessary" routines. I wouldn't be opposed to a libsif either. We would have to do a major release to justify that though.
The argument is not for old stuff that is painful to change. If you're submitting something new I don't see what's the big deal with splitting it out now, esp. since you've just added it and so no one else has used it yet.
As far as the other stuff in libkernel, SIF stuff was there before I started dealing with it and IIRC no one felt it had to change into it's own lib. libc stuff we also came to a consensus after a back and forth over how to do it (check the ps2dev/ps2cvs ML archives, it should be there). There's a history behind the libc stuff even before mine made it into ps2lib, because there used to be a mini-libc in ps2lib that was gutted in favor of newlib. Once folks saw newlib was crap the consensus was to move libc back into ps2lib, and libkernel was the chosen library because: a) it is always linked to the application (if you're using ps2lib, of course), b) libc depends on libkernel, and c) we didn't expect to need/use all of libc, just a few "necessary" functions. Besides SIF and libc, all that remains in libkernel is syscalls and other glue code which does actually belong in libkernel.
TBH, I wouldn't be opposed to splitting out libc, considering that it has grown way beyond just a few "necessary" routines. I wouldn't be opposed to a libsif either. We would have to do a major release to justify that though.
-
blackdroid
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
Unfortunately there are no written rules, except from ideatossing on the mailinglist, but generally each subcomponent of the ps2 should end up in its on lib, for me its logical to have libgs, libdma, libsif etc. Now this is my opinion, and maybe not shared by everyone, but this is a forum we discuss, and eventually we reach a consensus.ooPo wrote:Perhaps now would be a good time to actually state what the purposes of each part of ps2lib are. What exactly is a libkernel? Should we have a libsif, libsyscall, libwhatever? Where is the line drawn? The only time I get information like this from you folk is after I've actually done it.
There is no need to do the cry baby dance, you went out and did something, great. But as you have noticed there are plenty of opinions :)In any event my brief stint with code contribution has met with the standard ps2dev resistance. I'll go back to doing my own codebase now. Sorry for the trouble.
Kung VU
*wah* *cry*
I'm just tired of asking and asking and getting no response. Then when I put something out I get a long list of people saying that I'm wrong. I think one of my first questions on the channel was 'What is ps2lib supposed to do? Does it do anything?' There's a lot of code there that doesn't do very much, and a lot of redundant 'fixme' code.
It sounds like libkernel is supposed to be just a wrapper for syscalls.
Toss the whole thing, I say. :)
I'm just tired of asking and asking and getting no response. Then when I put something out I get a long list of people saying that I'm wrong. I think one of my first questions on the channel was 'What is ps2lib supposed to do? Does it do anything?' There's a lot of code there that doesn't do very much, and a lot of redundant 'fixme' code.
It sounds like libkernel is supposed to be just a wrapper for syscalls.
Toss the whole thing, I say. :)
-
Oobles
- Site Admin
- Posts: 347
- Joined: Sat Jan 17, 2004 9:49 am
- Location: Melbourne, Australia
- Contact:
Exactly.. toss the whole thing and build ps2sdk. :) That was its purprose, to start clean. The directory structure for it and design is on the topic ps2dev & ps2cvs mailing list in ~early january this year.
There had already been a previous decision that ps2lib shouldn't be changed further. However, having stated that. If you are going to add more. A libgs imo is needed. libkernel should only be for accessing the internal system calls and c library.
My 2cents..
Oobles.
There had already been a previous decision that ps2lib shouldn't be changed further. However, having stated that. If you are going to add more. A libgs imo is needed. libkernel should only be for accessing the internal system calls and c library.
My 2cents..
Oobles.
I have removed the code from cvs as your inbox has probably already shown. I am posting this message to provide closure to those viewers who aren't on the cvs list.
As for ps2sdk... perhaps it would be easier to split the idea of what you're looking for into pieces and pass them out to whoever wants to champion them. Stamping a name like ps2sdk on it makes it seem insurmountable and nobody wants to start taking stabs at it.
As for ps2sdk... perhaps it would be easier to split the idea of what you're looking for into pieces and pass them out to whoever wants to champion them. Stamping a name like ps2sdk on it makes it seem insurmountable and nobody wants to start taking stabs at it.