> Wondefull. But there are hundrets of nice ripper/encoder frontends
> outhere, but that's not related to an fs that makes traks of an audio
> cd aviable as files.
As someone who has written an extremely sophisticated audio cd filesystem,
I must say that I completely agree with Jens. It's a BAD IDEA. Actually,
he yelled at me about this about a year ago :) This would be a great
topic to add to the FAQ!
There are two schools of thought:
1) Things like jitter and scratch correction are not obvious kernel
functionality. They bloat the kernel and can be done just as
effectively in user space. Implementing corrections for drives
that do it with hardware is a waste. Not implementing corrections
is inadequate for the rest. The whole idea behind standards like ide
and SCSI is that the drivers can be more generic.
2) The CD-ROM is a device, and doing corrections are the job of the
driver. However, the audio sector size is bigger than the pagesize
and this means doing translation if the filesystem is to use the
normal blkdev approach.
The inodes and superblock would all have to be virtual since the only
directory structure on an audio cd is the TOC. I have no problem
with this, personally.
This means that the cd drivers (all of them) would need to be changed
to translate between pagesized blocks and framesize blocks and then
have a fairly intricate cache scheme. Otherwise, the audiofs
implementation would need to make ioctl() calls. I, for one, don't
think that the kernel should use ioctl's. Personally, I don't like
them because the kernel has to turn off memory write verification
using get_FS() and set_FS(). I'm not happy about that.
Now, honestly, do you think Option (2) is worth all that? Having
implemented it all (for fun, mainly) I can tell you to stick with the
userspace rippers/encoders. They are the right way to go.
However, (JENS, what's your opinion on this?) it might not be a bad idea
to put the audio commands under the procfs. Currently, they can only be
done via ioctl's.
JM
JM Geremia
307 Frick Laboratory
Princeton University
Princeton, NJ 08544
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:15 EST