Messages in this thread | | | From | "D. Hazelton" <> | Subject | Re: CD writing in future Linux (stirring up a hornets' nest) | Date | Sat, 18 Feb 2006 19:29:30 -0500 |
| |
On Saturday 18 February 2006 11:56, Bill Davidsen wrote: > D. Hazelton wrote: > >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. > > I would think that the model, manufacturer and serial would be useful, > and just the indication that the device was CD capable would be a huge > gain. There are at least two more type of drive coming soon in the 25GB > media race, so identification could legitimately be left to the > application as long as all CD-like devices can easily be identified for > examination. > > Does that fit with your level of available time (and interest in > resolving this issue)?
seems straightforward enough. May take me a bit, since I'll need to see what has to be done in order to make the information necessary, but I think it could all be resolved with calls to the routines the ioctl's normally access.
DRH
(and I think that theres even more information available, from the capabilities mode page, but I'm unsure as to how to access that) - 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/
| |