On Monday 31 March 2003 08:40, Andrey Borzenkov wrote: > [Danny, you do know I do not get cooker, do not you? :)] yes, sorry. > > I plan to add support fot CDEJECT (or similar) to sd and make > eject program to try next method only if previous one returned > ENOSYS. It won't fix it for all cases but will for most common usage. would be nice;) > > >> (It is possible to lock device only on rw operations. Suggestions > >> are welcome). > > > > why not? > > because I do not want to make it default and it makes code > messy if done conditionally. If there is enough demand ... Well, diskdrake could add no_tray_lock as a default option.
> > I won't shoot you but it is _not_ what supermount should be doing. I figured so. > > > I'd like to see a transparent way of access to audio cds (and vcd > > and the like). There is something already doing this called cdfs > > IIRC, haven't looked at it for some time. But currently GUI apps > > try to do this kinda thing by implementing things like audiocd:// > > io_slaves and the like. A very silly solution, why doesn't the > > kernel handle this? > > Possible reasons: > > 1. because nobody was motivated enough to do it good reason. > 2. because it is easily done using user-level tools so adding this > to kernel just bloats it without any obvious advantage Each program is implementing this in his own obscure way. Many new users have no clue as to how play CDS with xmms, have no idea you actually can type audiocd:// in konqueror, and complain that audio CDS in general do not work. If it does not belong in kernel (I've heard that argument for supermount as well, but ok), than lets up someone creates a libaudiofs which all programs will use (but I doubt this will let me: 'cd /mnt/cdrom; cp track*.* ~/' ?) d.
