Messages in this thread |  | | | Date | Tue, 31 Jan 2006 23:49:58 -0500 | | From | Albert Cahalan <> | | Subject | Re: CD writing in future Linux try #2 |
| |
On 1/31/06, David S. Miller <davem@davemloft.net> wrote:
> Someone remind me why the whole world is a prisoner to Joerg's cd > burning program? > > Anybody can write their own, and if Joerg is a pain to work with that > is a double extra incentive for this other implementation to be > written. > > In fact I'm very surprised this hasn't happened already.
It has happened, many times, but sustaining such a project is very difficult. The obstacles are numerous:
All the GUI apps parse cdrecord output. The output is somehow even messier than the recent /proc/*/smaps abomination. It is thus difficult to change or replace cdrecord. One of the major GUI apps appears to be written by Joerg's real-life non-Internet friend, who naturally refuses any patches to eliminate the need for cdrecord. Joerg is a Fraunhofer employee. That gives him connections to many hardware companies. (and the RIAA, MPAA, Sony, Disney...) One may wonder if this is both blessing and curse.
Forking means dealing with a giant pile of messy and ugly code. The coding conventions are... interesting... and this code has to run setuid. One had better be really careful making changes. Most people are clueless about setuid code.
Starting fresh means rediscovering firmware bugs, of which there are many. Things may be getting somewhat better though, with the old pre-standard interfaces hopefully dying out. Getting the most out of the hardware will require lots of device-specific code.
Joerg gets the hardware.
There are all sorts of funky formats. I've only ever heard of mixed audio+data CDs for circa-1995 games and Sony spyware, but maybe there are decent people who actually create these things. In theory, somebody might be making multi-session CDs. Who knows?
That all said, I just wrote /dev scan code and I'm about half way through documenting xcdroast's cdrecord expectations. I'm imagining something like this:
/usr/lib/burner-helper: setuid or daemon, controlled via stdio /usr/lib/something.so: interacts with burner-helper /usr/bin/cdrecord: the crappy legacy interface /usr/bin/something: a non-crappy CLI interface
(no promises) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |