>>> Probably, it would be best to make a driver (similar to loop)
>>> with a number of minors equal to the number of CDs you will
>>> support. Make each CD it's own device, and then the user can
>>> mount them normaly.
>> Well, the problem with this scheme is that the jukebox I am
>> working on has hundreds of CDs so taking into account partitions
>> on CDs would mean thousands of minors. This is not reasonable with
>> our current dev_t. It could work with devfs or a larger dev_t, I
>> guess. It still seems like representing this jukebox as thousands
>> of files in /dev is messy at best.
> Hmmm... I'd tend to maintain that keeping each disk a sepperate
> device would be cleaner then the other way around. However, your
> right that for a huge disk array (well, huge to me -- I don't think
> I've ever used a machine /w more then one CDROM drive though) you
> would use huge amounts of minors (though you could pre-scan for
> multiple partitions, instead of allowing room for 16 for each CD).
> However, I think one device, one medium is a good rule -- what if
> sombody wants to cat out the whole CD? (Or do "cdid
> /dev/cdjukebox115" to see what CD #115 has on it?)
A variant of that might make more sense here - perhaps have the
/dev/jukebox (or whatever) as the device number for the entire jukebox
array, similar to the RAID devices. One could then have that as a
pseudo-directory that has a separate [directory] entry for each
available CD similar to the virtual /proc file system's method of
'storing' files...
This would mean that a system with two 3-changer drives would appear
something like the following listing:
Q> $ mount /dev/jukebox /mnt
Q> $ ls -la /mnt | tr -s ' ' | cut -d ' ' -f 1,9-
Q> dr-xr-xr-x A0
Q> dr-xr-xr-x A1
Q> dr-xr-xr-x A2
Q> dr-xr-xr-x B0
Q> dr-xr-xr-x B1
Q> dr-xr-xr-x B2
Q> $ umount /mnt
The letter would be used internally to identify which drive, and the
number that followed would say which disc from that drive...one could
easily support MILLIONS of disks that way...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu