> Right now we have a problem with no good solution: one is a dangerous
> cleanup function that will lead to "unexpected" behaviour and the =
> is no cleanup function which will lead to... "unexpected" behaviour. =
> root of this problem is that a difference may exist between allocated
> ressources and used ressources (program crash or cleanup function will
> both create this mess).
> Since both approaches result in a messy situation I think it's better =
> do nothing *at the API level*. We can give example code (cfr David
> Moore), provide a button in Coriander, write this in the FAQ, use =
> warnings, etc...
Well, the first messy situation comes when one actually uses more than =
firewire device from different applications and purposefully hits the =
which cleans up the bus.
The second messy situation appears if one pulls a cable and plugs it =
In this case even configurations with just one firewire device, IMHO a =
more frequently encountered configuration, also the one more commonly =
by users who might need a hard bus reset at all.
> > One other thing: Obviously it is possible to find all cameras on the
> > firewire bus. Why is it impossible to kick out all camera related =
> The problem is not much about which camera is using what (this is =
> but rather which program is using which camera (difficult once the
> program is dead). Kicking all IIDC ressources will still break other
> apps that are also using IIDC cameras. IMHO the real solution can only
> come from the kernel (probably via libraw1394).
This again implies that there are several cameras on the bus. I agree =
in a perfect world a clean library should be able to handle that but =
the linux kernel hasn't reached perfection yet :-)
In the mean time it would be nice to have an escape pod for those
with one camera attached. Any reasonable GUI programmer will pop up
a window asking the user before a bus reset is issued.
> > So for now the only thing we can do is indeed say to the programmer =
> > fix his program ;) I know it's not a good attitude but I fear we =
> > nothing appropriate to offer. Of course if there is correct program =
> > can lead to an ressource allocation issue then we have to fix it in
> > libdc1394.
Well, if all we can offer is an unsafe function which resets the bus,
I think we should go ahead and just do that. The main reason why I am
unhappy with the raw1394 aproach is that it is not needed and will not
work for Mac OSX. I hoped that dc1394 would abstract the raw1394 away
so I could use one code base for linux and Mac. If we reintroduce the=20
need for raw1394, we need #ifdef again :-(
> At last, we can also kick this automatic ressource allocation out of
> libdc and wait for a good kernel base. I have to admit I may have been
> going a bit far by adding this early.
Please remove the function not before a stable kernel is available
in standard distros which handles firewire correctly.