>Betreff : [linux-minidisc] introduce recorder/filesystem concept split; move autodetection to libhimd >Gesendet: 28.11.2010 00:38:05 >An : "linux-minidisc@lists.fu-berlin.de" >Von: "Michael Karcher <Michael.Karcher@fu-berlin.de>" >----- Originale Nachricht ----- >My suggestion is to have a two-tier system - recorders and media. First >we detect recorders, that have (at least) the following properties: > - physical path (/dev/sdb on Linux, either E:\ or \\.\PHYSICALDRIVE3 on >Windows, whatever we need for libscg.) There is no windows driveletter support in libscg. On Windows we need the physical path in the form <scsibus>:<target>:<lun>. We should iterate over all scsibusses, targets and luns to find himd devices by vendor and product ids as connected himd devices have no driveletter assignment if no medium is present at connection. (We will recieve DBT_DEVICEARRIVAL message when medium is inserted) And then we could iterate over all drive letters trying to open as a scsi device and compare its scsibus, target and lun if successful to find the corresponding mountpoint and fill our medium structure. During runtime DBT_DEVICEARRIVAL and my_GUID_IO_MEDIA_ARRIVAL btw. REMOVAL messages are used to add/free the recorder and medium structures. Maybe we can add a device path to the recorder structure on windows holding the driveletter, but this will work on windows only as the driveletter is a fix path to the device. If no medium is inserted and we unplug the device there is no medium structure holding the corresponding recorder structure. On DBT_DEVICEREMOVAL message we only have the driveletter and cannot try to open as a scsi device as it is not present anymore and so we cannot find the correspondig scsi device for the driveletter which is removed unless we are iterating over all scsi devices as on application start. By adding the device path (driveletter) to the recorder structure we can find and free it. > - device name ("Sony MZ-RH1") > - pointer to a medium structure (is NULL if no medium inserted). >And the medium structure has (at least) the following properties: > - mounted path (e.g. "/media/disk_" on Linux, or E:\ on Windows) > - pointer to recorder structure (is NULL if a Hi-MD copy is opened). >As we see, there is no 1:1 relationship between these two structures, >that's why I suggest the split of these info. What do you think? >Furthermore, I suggest moving the himd detection stuff to libhimd, to >prepare SCSI support integration (which needs to deal with physical >devices) in libhimd. >Regards, > Michael Karcher Ok, sounds good. For autodetection during application runtime in libhimd we should use DBus Glib binding and test windows and mac ports of DBus as there are no glib bindings for windows and mac system bus messages. To avoid polling to get qhimdtransfer informed when a device/medium is added/removed we can use DBus, too. Thomas