forums.ps2dev.org

[KaylaKaze]

Can someone with CVS access change the part of hddGetFilesystemList that says

[TyRaNiD]

Get a cvs account then you can do it yourself.

[KaylaKaze]

I don't know how to use CVS very well. Just enough to tell WinCVS to checkout. I'd be worried I'd break something.

[TyRaNiD]

Some would say adding support for HDL partitions would be breaking things :)

[emoon]

We dont want any HDL/HDA patch shit in our sdk, HDL/HDA is warez and so it is.
Trying to go around it with lame stuff like this is to approve the existense of it.

[KaylaKaze]

That's BS. It exists. Deal with it. Ignoring it won't make it go away. It'll just screw up the homebrew scene when peope can't get a program to load in a timely manner. Just because you acknowledge the existence of something enough to get around the problems it causes doesn't mean you approve of it.

[ooPo]

We're not ignoring it, we're just not supporting it.

[blackdroid]

Homebrew scene for me doesnt involve HDL or HDA.
_________________
Kung VU

[emoon]

Adding a patch to make copyright violations convenient is certainly an approvement of it.

[KaylaKaze]

I'm not talking about supporting it. What part of the patch makes you think it's being supported? It's merely making GetFilesystemList not take freakin' forever if there are HDL partitions on the system by skipping them. How is that supporting it? Oh well, do whatever, I guess I'll just be the only one writing software that uses the hard drive that doesn't take a year and a half to load.

[ooPo]

Just how many HDL partitions do you have, anyway?

[Drakonite]

[KaylaKaze]

I don't know. I've never counted. I've got a 120GB HD. 3 or 4 gigs is PFS formatted. It took MCManager at least a minute (though I think closer to 2, I never timed it) to load before I changed it to not scan for partitions. I noticed a lot of people thinking HD programs were locking up on their systems they were taking so long.

I've never seen the code for HDL so I don't know which aspects of it make it a copyright violation so I can't answer to that. The point is that people aren't going to stop using it and reformat their drives just because someone releases some new homebrew that reads from the HD. They'll just stop using the homebrew 'cause it takes too long to load. I don't know if the mode!=PFS would work as well as the name filter, but if you did that, it'd be for ignoring ANY unaccessible partition, not necessarily HDL. To me getting a list of ACCESSIBLE partitions is a function that should exist anyway. (of course, by accessible, I mean accessible by PFS).

[KaylaKaze]

[ooPo]

Piracy talk aside, hacking in code to work around one specific program is rarely a good idea. Finding out why it takes so long to scan invalid partitions rather than just skipping them would be a better goal, and possibly more acceptable to people here. Try submitting a patch that adds to the value of the software as a whole instead of one that bends it around a problem that's really just yours, not ours.

...and if you want a true debate on the merits of ps2dev supporting software like this, you'll have to come up with a better point than 'everyone is doing it!'.

[Drakonite]

[KaylaKaze]

My point isn't everyone else is doing it. My point was it's a problem that exists and should be taken into account, whether you like it or not.

And the one specific program thing is why I suggested possibly making an alternate function that skips and non-PFS partition.

As far as WHY it takes so long, it's just the number of partitions, and the time consuming routines done on each. There's no way to fix it except by skipping some of them or for the user to remove them. If you have... say 60 PFS formatted partitions, it'd take just as long, I'm sure. So you look at how it affects the average user and you see they only have 1 or 2 PFS partitions and 58 other partitions and it's taking forever. You know your program can't do anything with those 58 partitions, so there's not really any need for your program to know about them, so you can skip them, thus saving time. If you're developing something that's not just for yourself, you have to take the average user into account, not your own situation. Just because you only have 3 or 4 partitions doesn't mean you should code like everyone does. If this wasn't about HDL partitions but some homebrew something that made shloads of custom partitions and took huge amounts of space, you wouldn't be arguing.

[Neil Stevens]

60 partitions? Sounds like some pretty inefficient software you're using, if you have to create 60 partitions.

Or is this not the PC-style logical partitioning I'm thinking it is?

Surely ps2dev shouldn't add hacks to support broken software, legal or not.

[KaylaKaze]

[ooPo]

I see your point about any hdd with that many partitions, hdl or not, would be slow to start. However, I am unconvinced that adding a workaround for one program is a proper solution - it will only work until some other program creates a bunch of partitions as well.

I can see two ways of fixing this:

1) Use of threads in the homebrew program to enumerate the partitions while the UI continues to function, thus removing the 'lockup' impression the user is experiencing.

2) In ps2sdk, determine if it is indeed a speed issue or possibly a bug that causes the lengthy process and fix or optimize where any issues are found.

Either can be acomplished without the need to resort to yelling at us for not bending over backwards to support users who chose to run the hdloader software. You've managed to uncover a serious performance issue in ps2sdk, even if by the wrong means, so let's concentrate on the problem instead.

[Drakonite]

[pixel]

Sjeep did that "on purpose". I am strongly against any "workaround" in the current ps2sdk to support software which was made, on purpose, to choke the other homebrew software with tweaked partitions. If HDL was a homebrew software, I'd rather go on fixing it than workarounding it in the sdk.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[KaylaKaze]

I was only yelling 'cause I got yelled at first, and because all of you seem to shut down your brains at the mere sight of the letters HDL. I apologize. I'm sure it seems a reasonable reaction to you. It doesn't to me.

As far as the speed of PS2SDK during GetFilesystemList, I don't think it's PS2SDK's fault; it's just the time it takes to get all that info from the HD, probably bottlenecked by the HD access and read speed. One way I can see to fix it easily without it mattering what format the partitions were would be to make it just return the dirEnt info (name, stat) since that's all you REALLY need to know on enumeration. Anything else (getting partition size, partition type, and all those other intensive things Get FilesystemList does) can be done through other functions when needed and on specified partitions, not on all. Doing it this way, you wouldn't have to skip anything. The problem I see with loading this info in the background is if the program or user tries to access the data before it's been completely enumerated.

In case that was too rambling to make sense: GetFileSystemList does more than it needs to, which makes it slower than necessary, and would probably be better split into multiple functions.

[KaylaKaze]

[pixel]

To be really honest, I have as much pro and cons about a homebrew HDL software. pros is that hdl already exists, and having a homebrew one wouldn't do any more harm than hdl already did; and such software may still be cool as it could get lots of improvements from various locations. cons is that it's just not like us in any way, because it would still be a warez-enabled tool and used as it by 99.99% of the users of it.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[Guest]

Kayla, first off, you have a point about getting jumped on. However, you have been around these forums long enough to have known it would happen, whether either viewpoint is right or wrong. Not saying you shouldn't have tried anyhow.

Second, I like Oopo's approach - if anything needs fixing, fix real problems in a general way for the good of all, rather than focusing on something that caters to a specific app that itself is extremely controversial.

My own view, as someone who tried the ps2menu-k+hdl combo (I know, heresy in these parts) with games that I own is that the loading speeds were really not that big a deal for me to make it worth it to use hdloader. I honestly could not see any perceived benefits of loading speeds for legally-owned games being compelling enough to overcome the obviously more serious and most likely use that others would put it to - warezing.

I have long since nuked that partition and software.

[rinco]

Please don't use ps2sdk to develop copyright circumvention software.

Please don't use ps2dev forums to collaborate on planning or developing
copyright circumvention software.

Please don't get ps2sdk/ps2dev banned in my country.

[cory1492]

[BraveDog]

Well, staying out of the warez discussion, how about this.
Have hddGetFilesystemList() stay the same and add two new functons.
hddGetFilesystemNames(char names[], int maxEntries)
'just returns a list of the valid partition names'
hddGetFilesystemInfo(char *name, t_hddFilesystem *fs)
'Pass in the filesystem name and it returns the info in the fs pointer.

This would give people the flexiblity to do what they want.

I guess it might make sence to have hddGetFilesystemList() call the new
hddGetFilesystemInfo() so the logic is not duplicated.

[ooPo]

Writing a couple new functions won't fix it. Take a look...