Re: CD writing in future Linux (stirring up a hornets' nest)

["D. Hazelton" <dhazelton@enter.net>]

On Friday 17 February 2006 16:35, Bill Davidsen wrote:
> Daniel Barkalow wrote:
> > I don't think it needs to be a class, but I think that there should be a
> > single place with a directory for each device that could be what you
> > want, with a file that tells you if it is. That's why I was looking at
> > block/; these things must be block devices, and there aren't an huge
> > number of block devices.
> >
> > I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I
> > hadn't dug far enough in to realize that the reason I wasn't seeing
> > anything informative in /sys/block/*/device/ was that I didn't have any
> > devices with informative drivers, not that it was actually supposed to
> > only have links to other things.
>
> It would be nice to have one place to go to find burners, and to have
> the model information in that place. I would logically think that place
> is sysfs, and I know the kernel has the information because if I root
> through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
> eventually find out what the system has connected.
>
> I not entirely sure about having classes other than cdrom, just because
> we already have CD, DVD, DVD-DL, and are about to add blue-ray and
> HD-DVD, so if I can tell that it's a removable device which can read
> CDs, the applications have a fighting chance to looking at the device to
> see what it is. As a human I would like the model information because
> the kernel has done the work, why should people have to chase it when it
> could be in one place?

The problem is that drives don't always cleanly report what they are in a 
simple to access format. All SCSI and ATAPI drives provide a model, 
manufacturer and serial number but usually the type of drive is buried within 
the Model field, and that has a lot of variations.

(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM)

Now what could be done is that said information could be exported to sysfs. 
Given the time I could probably manage the patch myself, but I'm currently 
overextended with the number of projects I have underway.

DRH
-
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/