Re: [linux-minidisc] introduce recorder/filesystem concept split; move autodetection to libhimd
>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
