And how do you define 'first' in a way that is compatible to all old drivers and their methods for scanning the USB bus for devices ? And don't forget the possibility of hubs, using which I have had access to as many as 4 different storage devices at one time in SMS...Quote:
Originally Posted by suloku
In a new driver this can always be solved, in many different ways, but the real problem is with old applications having built in drivers with no idea about which of the connected USB drives should be considered the 'valid' mass: drive.Quote:
Or remount the drive before launching the elf file if it's not already mounted as "mass:". That wouldn't really be a problem as the second device doesn't have the need to be mounted when the user starts the elf.
We also need to consider the fact that some conflicting standards already exist both in normal homebrew usage and in drivers used by commercial programs. One obvious way of extending the "mass:" device is by using "mass0:", "mass1:", etc. And personally I'd prefer this method to the "ums0:", "ums1:" usage of the SMS drivers. But if the SMS drivers were open for use by others, then it might be easier to patch old programs to use those drive names, as the string length is the same as for the old "mass:" name.
But for compatibility to old drivers we'd need to be sure that they all scan drives in such a way that all of them will activate the same drive, which is by no means certain.Quote:
Of course that's assuming the src and that the first device is mounted to mass: and the second to anything else.
eg:
Using the official usbhdfsd.irx driver embedded in uLE I just tried to access the "mass:" device with two USB storage devices connected. One to the topmost USB connector of my v7 PS2 (thus IMO the 'first' USB device) and the other one to the third of four connectors of a USB hub plugged into the other USB connector of the PS2. The first two connectors of that hub are used for my USB keyboard and mouse. With this setup access of "mass:" reaches only the drive connected to the hub (a USB pendrive in this test) completely ignoring the drive connected directly to the PS2 (a USB HDD in this test).
Switching around the order of the two connectors of the PS2 and rebooting for a new test reverses this result, so that the drive connected directly to the second USB connector is seen as mass: instead of the drive connected indirectly via hub to the first USB connector.
This also matches the results when more than one partition of a USB device has FAT32 filesystem, as the usbhdfsd driver will then use the last of those partitions as mass:.
So the logic used here is that the last FAT32 USB partion found in scanning all connected drives and all their partitions will be used by usbhdfsd for mass:, while the usage order of SMS is different in two ways. It will make the directly connected drive appear as "ums0:" regardless of which of the two PS2 USB connectors is used for that drive and which is used for the hub. The other difference is that SMS only scans for the first partition of a drive, so if that is not useful (eg: NTFS) then SMS will not proceed to use the next partition even if that does work.
In all, there are a lot of complications to consider here, in trying to define a new multi-drive and multi-partition mass: standard.
I believe that the best results would be achieved by working from the sources of EEUG for his new drivers, but modifying them to allow access to a 'main' drive as "mass:" for compatibility reasons (possibly also adding mass0:, mass1:, etc).
But since SMS is not an open-source project, we can't use its driver sources unless EEUG decides to make them public.
Best regards: dlanor
