[opensuse-factory] Device names in openSUSE
Hi! I submitted the following bugreport (bnc#717326): === The current Lanana devices list http://www.kernel.org/pub/linux/docs/device-list/devices.txt reserves sd* name for SCSI block devices, while USB devices should have name of the type ub*: USB block devices 0 = /dev/uba First USB block device 8 = /dev/ubb Second USB block device 16 = /dev/ubc Thrid USB block device But in openSUSE USB devices are actually assigned names in sd* range making automatic device type detection impossible or difficult. I faced this issue when making a patch for KDE3 that should detect removable media without hal and which is based on analysis of /proc/self/mounts entries. Thus the mtab backend thinks about USB drives as of hard disks. === It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names. Another question is that it seems that even SATA and parallel IDE devices also receive the SCSI-name. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Sep 12, 2011 at 11:11:52PM +0400, Ilya Chernykh wrote:
Hi!
I submitted the following bugreport (bnc#717326):
Thanks, but no need to report it here, I've marked it invalid :)
=== The current Lanana devices list http://www.kernel.org/pub/linux/docs/device-list/devices.txt reserves sd* name for SCSI block devices, while USB devices should have name of the type ub*:
USB block devices 0 = /dev/uba First USB block device 8 = /dev/ubb Second USB block device 16 = /dev/ubc Thrid USB block device
That is if you are using the ub.ko kernel driver, which no one does anymore, it is not needed. Normal usb devices use the usb-storage driver, which use the scsi device naming scheme, as you have noticed. That is the correct thing to do.
But in openSUSE USB devices are actually assigned names in sd* range making automatic device type detection impossible or difficult. I faced this issue when making a patch for KDE3 that should detect removable media without hal and which is based on analysis of /proc/self/mounts entries.
Why would you do that? Why not use the proper api to detect removable block devices and not rely on the device name?
Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names.
No it isn't, it's been that way for over 10 years now, nothing new here at all
Another question is that it seems that even SATA and parallel IDE devices also receive the SCSI-name.
Again, on purpose, has been this way for over 5 years now. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 09:07:04 you wrote:
Thanks, but no need to report it here, I've marked it invalid :)
=== The current Lanana devices list http://www.kernel.org/pub/linux/docs/device-list/devices.txt reserves sd* name for SCSI block devices, while USB devices should have name of the type ub*:
USB block devices 0 = /dev/uba First USB block device 8 = /dev/ubb Second USB block device 16 = /dev/ubc Thrid USB block device
That is if you are using the ub.ko kernel driver, which no one does anymore, it is not needed.
Normal usb devices use the usb-storage driver, which use the scsi device naming scheme, as you have noticed. That is the correct thing to do.
It is obviously incorrect, if to follow the Lanana specification, and any intuitive logic. Why this driver uses SCSI names for USB devices?
But in openSUSE USB devices are actually assigned names in sd* range making automatic device type detection impossible or difficult. I faced this issue when making a patch for KDE3 that should detect removable media without hal and which is based on analysis of /proc/self/mounts entries.
Why would you do that? Why not use the proper api to detect removable block devices and not rely on the device name?
There are different backends that use different methods. Currently KDE3 has two backends: a HAL backend that uses HAL api, and mtab/fstab backend that scans mtab table. HAL backend will be useless in a system without hal. Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
Still this is incorrect, there in a "removable" device type that should be used. When using hal, the usb drives are shown with "flash drive" icon.
It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names.
No it isn't, it's been that way for over 10 years now, nothing new here at all
As I already said this contradicts at least the Lanana specification adopted in 2009. Even if this was the case for a long time, it obviously contradicts the modern specification.
Another question is that it seems that even SATA and parallel IDE devices also receive the SCSI-name.
Again, on purpose, has been this way for over 5 years now.
On which purpose and why this purpose is not reflected in specification? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 02:08:10PM +0400, Ilya Chernykh wrote:
On Tuesday 13 September 2011 09:07:04 you wrote:
Thanks, but no need to report it here, I've marked it invalid :)
=== The current Lanana devices list http://www.kernel.org/pub/linux/docs/device-list/devices.txt reserves sd* name for SCSI block devices, while USB devices should have name of the type ub*:
USB block devices 0 = /dev/uba First USB block device 8 = /dev/ubb Second USB block device 16 = /dev/ubc Thrid USB block device
That is if you are using the ub.ko kernel driver, which no one does anymore, it is not needed.
Normal usb devices use the usb-storage driver, which use the scsi device naming scheme, as you have noticed. That is the correct thing to do.
It is obviously incorrect, if to follow the Lanana specification, and any intuitive logic. Why this driver uses SCSI names for USB devices?
Because USB storage devices are really just SCSI devices, look at the USB storage spec for details if you are curious. The ub driver was an attempt to handle the fact that for a while in the 2.4 kernel days the SCSI stack could not handle removable devices in a stable manner. For 2.6 this really wasn't needed anymore so the distros stopped enabling the ub driver, but it remains for those few users who don't want an entire SCSI stack for a single USB device.
But in openSUSE USB devices are actually assigned names in sd* range making automatic device type detection impossible or difficult. I faced this issue when making a patch for KDE3 that should detect removable media without hal and which is based on analysis of /proc/self/mounts entries.
Why would you do that? Why not use the proper api to detect removable block devices and not rely on the device name?
There are different backends that use different methods. Currently KDE3 has two backends: a HAL backend that uses HAL api, and mtab/fstab backend that scans mtab table. HAL backend will be useless in a system without hal.
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
Still this is incorrect, there in a "removable" device type that should be used. When using hal, the usb drives are shown with "flash drive" icon.
That's wrong then, fix HAL :)
It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names.
No it isn't, it's been that way for over 10 years now, nothing new here at all
As I already said this contradicts at least the Lanana specification adopted in 2009. Even if this was the case for a long time, it obviously contradicts the modern specification.
Again, no, it does not, your USB device is really using the SCSI stack, so it is a SCSI device.
Another question is that it seems that even SATA and parallel IDE devices also receive the SCSI-name.
Again, on purpose, has been this way for over 5 years now.
On which purpose and why this purpose is not reflected in specification?
Because your SATA device is using libata which is using the SCSI stack. Having a consistant naming scheme for all block devices works out very well, and is not something that will be changed to go back to the old, broken days. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 10:22 AM, Greg KH <gregkh@suse.de> wrote:
On Tue, Sep 13, 2011 at 02:08:10PM +0400, Ilya Chernykh wrote:
On Tuesday 13 September 2011 09:07:04 you wrote:
Thanks, but no need to report it here, I've marked it invalid :)
=== The current Lanana devices list http://www.kernel.org/pub/linux/docs/device-list/devices.txt reserves sd* name for SCSI block devices, while USB devices should have name of the type ub*:
USB block devices 0 = /dev/uba First USB block device 8 = /dev/ubb Second USB block device 16 = /dev/ubc Thrid USB block device
That is if you are using the ub.ko kernel driver, which no one does anymore, it is not needed.
Normal usb devices use the usb-storage driver, which use the scsi device naming scheme, as you have noticed. That is the correct thing to do.
It is obviously incorrect, if to follow the Lanana specification, and any intuitive logic. Why this driver uses SCSI names for USB devices?
Because USB storage devices are really just SCSI devices, look at the USB storage spec for details if you are curious.
The ub driver was an attempt to handle the fact that for a while in the 2.4 kernel days the SCSI stack could not handle removable devices in a stable manner. For 2.6 this really wasn't needed anymore so the distros stopped enabling the ub driver, but it remains for those few users who don't want an entire SCSI stack for a single USB device.
But in openSUSE USB devices are actually assigned names in sd* range making automatic device type detection impossible or difficult. I faced this issue when making a patch for KDE3 that should detect removable media without hal and which is based on analysis of /proc/self/mounts entries.
Why would you do that? Why not use the proper api to detect removable block devices and not rely on the device name?
There are different backends that use different methods. Currently KDE3 has two backends: a HAL backend that uses HAL api, and mtab/fstab backend that scans mtab table. HAL backend will be useless in a system without hal.
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
Still this is incorrect, there in a "removable" device type that should be used. When using hal, the usb drives are shown with "flash drive" icon.
That's wrong then, fix HAL :)
It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names.
No it isn't, it's been that way for over 10 years now, nothing new here at all
As I already said this contradicts at least the Lanana specification adopted in 2009. Even if this was the case for a long time, it obviously contradicts the modern specification.
Again, no, it does not, your USB device is really using the SCSI stack, so it is a SCSI device.
Another question is that it seems that even SATA and parallel IDE devices also receive the SCSI-name.
Again, on purpose, has been this way for over 5 years now.
On which purpose and why this purpose is not reflected in specification?
Because your SATA device is using libata which is using the SCSI stack.
Having a consistant naming scheme for all block devices works out very well, and is not something that will be changed to go back to the old, broken days.
thanks,
greg k-h
Greg, On the libata list they occasionally fantasize about a day when libata will be a full fledged driver and not stuck underneath the scsi stack. It really doesn't belong there. sata does not truly follow the scsi standard, so its a force fit. When they have their flights-of-fantasy discussions, they talk about /dev/hd being a new universal name to represent all hard disks. Who knows if it will ever happen. It's been in the todo list for 5+ years I think. Greg (not KH) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 10:34:38AM -0400, Greg Freemyer wrote:
On the libata list they occasionally fantasize about a day when libata will be a full fledged driver and not stuck underneath the scsi stack. It really doesn't belong there. sata does not truly follow the scsi standard, so its a force fit.
When they have their flights-of-fantasy discussions, they talk about /dev/hd being a new universal name to represent all hard disks.
That would be nice, but then again, is a sd card a "hard disk"? Having all storage devices with the same namespace of "sd*" is the main thing that is important, and is what we finally accomplished. Changing the 2 characters to something else, as long as all devices use it, wouldn't be a big deal :)
Who knows if it will ever happen. It's been in the todo list for 5+ years I think.
I doubt it will, but it's nice to know the libata developers still are dreaming of it, thanks for letting us know. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Greg KH wrote:
That would be nice, but then again, is a sd card a "hard disk"? Having
and a sdcard in an usb reader :-) in fact my problem is the other way round, when some time a card with photos is openned as a camera and not as a disk, then I can't even use it. Could we have a list of cases where being seen as a mass storage don't work? thank sjdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 05:01:59PM +0200, Jean-Daniel Dodin wrote:
Greg KH wrote:
That would be nice, but then again, is a sd card a "hard disk"? Having
and a sdcard in an usb reader :-)
in fact my problem is the other way round, when some time a card with photos is openned as a camera and not as a disk, then I can't even use it.
That should work, it does for me, how does it fail for you?
Could we have a list of cases where being seen as a mass storage don't work?
don't work where? confused, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Greg KH wrote:
Could we have a list of cases where being seen as a mass storage don't work?
don't work where?
anywhere. I understand the thread as being a contest on disk name. I only see the contest valid if we have examples of non working system; May be the OP gave one, but I don't remember. if all works, why change anything? jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 21:16:41 Jean-Daniel Dodin wrote:
don't work where?
anywhere. I understand the thread as being a contest on disk name. I only see the contest valid if we have examples of non working system;
There are many cases when device types are misidentified. For example if I mount an ftp site via curlftpfs, Gnome shows it with a CD icon... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 18:51:47 you wrote:
On the libata list they occasionally fantasize about a day when libata will be a full fledged driver and not stuck underneath the scsi stack. It really doesn't belong there. sata does not truly follow the scsi standard, so its a force fit.
When they have their flights-of-fantasy discussions, they talk about /dev/hd being a new universal name to represent all hard disks.
That would be nice, but then again, is a sd card a "hard disk"?
What is really important is not what interface it uses, but whether it is removanle. All (or nearly all) USB drives are removable, that is they should not be shown as "hard drives" even if they are physically hard drives.
Having all storage devices with the same namespace of "sd*" is the main thing that is important, and is what we finally accomplished.
Accomplished what? Cannong all devices by a name, reserved to SCSI devices by the specification? Is this brutal breaking with the specification an achievement? By the way, DVD and CD drives still called sr*.
Changing the 2 characters to something else, as long as all devices use it, wouldn't be a big deal :)
Who knows if it will ever happen. It's been in the todo list for 5+ years I think.
I doubt it will, but it's nice to know the libata developers still are dreaming of it, thanks for letting us know. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 07:26:41PM +0400, Ilya Chernykh wrote:
On Tuesday 13 September 2011 18:51:47 you wrote:
On the libata list they occasionally fantasize about a day when libata will be a full fledged driver and not stuck underneath the scsi stack. It really doesn't belong there. sata does not truly follow the scsi standard, so its a force fit.
When they have their flights-of-fantasy discussions, they talk about /dev/hd being a new universal name to represent all hard disks.
That would be nice, but then again, is a sd card a "hard disk"?
What is really important is not what interface it uses, but whether it is removanle. All (or nearly all) USB drives are removable, that is they should not be shown as "hard drives" even if they are physically hard drives.
Why is that? What about people who boot from a USB disk, do you want to mark that as "removable"? :) I have ata disks attached to a PCI controller that I can hot-remove from the system at any time. Should those be marked "removable"?
Having all storage devices with the same namespace of "sd*" is the main thing that is important, and is what we finally accomplished.
Accomplished what? Cannong all devices by a name, reserved to SCSI devices by the specification? Is this brutal breaking with the specification an achievement?
We broke no "spec", sorry, please realize that USB disks showed up as "sd*" over 10 years ago, in the 2.2 kernel days. Then, in late 2.4 development, a totally new driver was written to resolve some issues. That was the ub driver, and at that time, the USB block major number was reserved that you see in the devices.txt document. At that time, most people still stuck with the usb-storage driver, and their disks showed up as sd*, and no distros enabled the ub driver. So at no point in time has any suse distro ever had a usb storage device show up as ub*. And neither has any other distro. So your code has _always_ been broken if it thought that ub* was the only way to detect a USB disk in the system.
By the way, DVD and CD drives still called sr*.
Sorry, you are correct, but they are still using the scsi subsystem. And note, your USB dvd drive also uses sr*. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Ilya Chernykh wrote:
On Tuesday 13 September 2011 18:51:47 you wrote:
What is really important is not what interface it uses, but whether it is removable.
sata devices *are* removable, external docks are more and more frequent (and very fast) jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 18:22:40 Greg KH wrote:
It is obviously incorrect, if to follow the Lanana specification, and any intuitive logic. Why this driver uses SCSI names for USB devices?
Because USB storage devices are really just SCSI devices, look at the USB storage spec for details if you are curious.
Wow. On my system all disks except the DVD drive are4 shown as with sd* name. Does it mean the SATA drive is also a SCSI drive? I also have an IDE drive attached via a parallel cable, is it also a SCSI drive? This becomes ridiculous.
There are different backends that use different methods. Currently KDE3 has two backends: a HAL backend that uses HAL api, and mtab/fstab backend that scans mtab table. HAL backend will be useless in a system without hal.
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
It is impossible to determine whether a given drive an USB drive or hard based on mtab only if the both use similar sd* name.
Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
Still this is incorrect, there in a "removable" device type that should be used. When using hal, the usb drives are shown with "flash drive" icon.
That's wrong then, fix HAL :)
This is completely correct. I insert a flash drive and see it as a flash drive.
It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names.
No it isn't, it's been that way for over 10 years now, nothing new here at all
As I already said this contradicts at least the Lanana specification adopted in 2009. Even if this was the case for a long time, it obviously contradicts the modern specification.
Again, no, it does not, your USB device is really using the SCSI stack, so it is a SCSI device.
Do you have a prooflink?
Another question is that it seems that even SATA and parallel IDE devices also receive the SCSI-name.
Again, on purpose, has been this way for over 5 years now.
On which purpose and why this purpose is not reflected in specification?
Because your SATA device is using libata which is using the SCSI stack.
Having a consistant naming scheme for all block devices works out very well, and is not something that will be changed to go back to the old, broken days.
Do you call it "consistent" when USB and ATA drives which have nothing to do with SCSI are shown as SCSI? This is not consistency. At best it is a weird hack. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 07:18:53PM +0400, Ilya Chernykh wrote:
On Tuesday 13 September 2011 18:22:40 Greg KH wrote:
It is obviously incorrect, if to follow the Lanana specification, and any intuitive logic. Why this driver uses SCSI names for USB devices?
Because USB storage devices are really just SCSI devices, look at the USB storage spec for details if you are curious.
Wow. On my system all disks except the DVD drive are4 shown as with sd* name. Does it mean the SATA drive is also a SCSI drive? I also have an IDE drive attached via a parallel cable, is it also a SCSI drive? This becomes ridiculous.
Please realize that this changed about 5 years ago. It is nothing new at all for anyone, so complaining now seems very strange to me.
There are different backends that use different methods. Currently KDE3 has two backends: a HAL backend that uses HAL api, and mtab/fstab backend that scans mtab table. HAL backend will be useless in a system without hal.
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
It is impossible to determine whether a given drive an USB drive or hard based on mtab only if the both use similar sd* name.
That is correct, which is why you should never use mtab for that as that is not what will correctly identify these types of devices. You are trying to have this interface do something it does not, and then complain when it is not correct. Shouldn't you consider that perhaps you should use something else instead to detect this?
Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
Still this is incorrect, there in a "removable" device type that should be used. When using hal, the usb drives are shown with "flash drive" icon.
That's wrong then, fix HAL :)
This is completely correct. I insert a flash drive and see it as a flash drive.
Having a USB disk drive (really an ata->usb connector) show up as a flash drive seems like the incorrect thing to do, don't you think so?
It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names.
No it isn't, it's been that way for over 10 years now, nothing new here at all
As I already said this contradicts at least the Lanana specification adopted in 2009. Even if this was the case for a long time, it obviously contradicts the modern specification.
Again, no, it does not, your USB device is really using the SCSI stack, so it is a SCSI device.
Do you have a prooflink?
Read the specification linked to at www.usb.org
Another question is that it seems that even SATA and parallel IDE devices also receive the SCSI-name.
Again, on purpose, has been this way for over 5 years now.
On which purpose and why this purpose is not reflected in specification?
Because your SATA device is using libata which is using the SCSI stack.
Having a consistant naming scheme for all block devices works out very well, and is not something that will be changed to go back to the old, broken days.
Do you call it "consistent" when USB and ATA drives which have nothing to do with SCSI are shown as SCSI?
It is "consistent" in that all storage devices are shown to the user through the same interface. And if you really want to detect the "type" of the device your block device is, then use the correct interface, not the incorrect one like you are trying to do. good luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 20:11:32 Greg KH wrote:
Wow. On my system all disks except the DVD drive are4 shown as with sd* name. Does it mean the SATA drive is also a SCSI drive? I also have an IDE drive attached via a parallel cable, is it also a SCSI drive? This becomes ridiculous.
Please realize that this changed about 5 years ago. It is nothing new at all for anyone, so complaining now seems very strange to me.
If the realization does not match the specification, this means either the realization or the specification is wrong, yes? And the specification was written in 2009, less than 5 years ago.
There are different backends that use different methods. Currently KDE3 has two backends: a HAL backend that uses HAL api, and mtab/fstab backend that scans mtab table. HAL backend will be useless in a system without hal.
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
It is impossible to determine whether a given drive an USB drive or hard based on mtab only if the both use similar sd* name.
That is correct, which is why you should never use mtab for that as that is not what will correctly identify these types of devices.
On *BSD and other Unixes this works well. Anyway there is no other choice rather than using mtab or hal. And mtab is the most universal way which is suitable for all unix-like systems, and not dependent on Linux.
You are trying to have this interface do something it does not, and then complain when it is not correct. Shouldn't you consider that perhaps you should use something else instead to detect this?
Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
Still this is incorrect, there in a "removable" device type that should be used. When using hal, the usb drives are shown with "flash drive" icon.
That's wrong then, fix HAL :)
This is completely correct. I insert a flash drive and see it as a flash drive.
Having a USB disk drive (really an ata->usb connector) show up as a flash drive seems like the incorrect thing to do, don't you think so?
I don't think so. This is exacly what I as a user expect. Also plugging in a camera shows as a camera when hal backend is used. Unfortunately this functionality will be gone in openSUSE 12.1. It is one of the reasons why I still recommend using hal-enabled kdebase3 package.
Do you call it "consistent" when USB and ATA drives which have nothing to do with SCSI are shown as SCSI?
It is "consistent" in that all storage devices are shown to the user through the same interface.
We were talking about name, not about interface. And actually it is not the case also: the CD and DVD are shown as sr* but USB and hard drives as sd*. Where is the consistency? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 08:39:57PM +0400, Ilya Chernykh wrote:
On Tuesday 13 September 2011 20:11:32 Greg KH wrote:
Wow. On my system all disks except the DVD drive are4 shown as with sd* name. Does it mean the SATA drive is also a SCSI drive? I also have an IDE drive attached via a parallel cable, is it also a SCSI drive? This becomes ridiculous.
Please realize that this changed about 5 years ago. It is nothing new at all for anyone, so complaining now seems very strange to me.
If the realization does not match the specification, this means either the realization or the specification is wrong, yes? And the specification was written in 2009, less than 5 years ago.
I think you are viewing the specification in the wrong order. The spec says, if userspace sees a block device with major number 180, and any minor number, then it must be called ub* and it will be a USB device and you can talk to it in that manner. The spec also says that if you see a block device with a major number of 8 and any minor number, then it must be called sd* and it will be a SCSI device that you can talk to in that manner. The spec does NOT say that all USB devices HAVE to use major number 180. That is what I think you are confused about here. The kernel is present to provide a consistent interface to userspace so that it knows how to interact with that device. If the kernel says the device is a scsi disk device, then you can talk to it like any scsi disk device, including sending special SCSI commands to it. And that is what is happening here, Linux exports USB mass storage devices as a SCSI device to userspace, and userspace knows how to handle it just fine, as does the kernel. The dev numbering and naming is NOT to be used to detect the "real" type of device that is being controlled here in any other way than what the correct way to interact with the device. If you want to determine if this really is a USB device or not, then you need to look elsewhere in the system, not in /dev. Same goes for firewire devices (also showing up as sd*), ATA devices (also showing up as sd*) and lots of other block type devices (SD cards, docking station devices, flash chips working like a storage device, etc.) So the spec, and the kernel is correct here, what is incorrect is in how you are trying to treat the spec. You are using it for something that it was not designed for, nor does it describe in any way. Hopefully this helps clear this up, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 14 September 2011 10:53:42 Greg KH wrote:
If you want to determine if this really is a USB device or not, then you need to look elsewhere in the system, not in /dev.
Out of interest, what is the correct way to determine if a particular device is removable, with hal gone? Is it the DeviceIsRemovable property in DeviceKit/udisk? Can that API be trusted to be stable? Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Sep 14, 2011 at 05:40:01PM +0200, Anders Johansson wrote:
On Wednesday 14 September 2011 10:53:42 Greg KH wrote:
If you want to determine if this really is a USB device or not, then you need to look elsewhere in the system, not in /dev.
Out of interest, what is the correct way to determine if a particular device is removable, with hal gone? Is it the DeviceIsRemovable property in DeviceKit/udisk?
Yes, I think it is.
Can that API be trusted to be stable?
I do not know, you should as the DeviceKit developers to be sure. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Sep 14, 2011 at 1:33 PM, Greg KH <gregkh@suse.de> wrote:
On Wed, Sep 14, 2011 at 05:40:01PM +0200, Anders Johansson wrote:
On Wednesday 14 September 2011 10:53:42 Greg KH wrote:
If you want to determine if this really is a USB device or not, then you need to look elsewhere in the system, not in /dev.
Out of interest, what is the correct way to determine if a particular device is removable, with hal gone? Is it the DeviceIsRemovable property in DeviceKit/udisk?
Yes, I think it is.
Are you avoiding /sys for some reason? If not, I vote for it being "cat /sys/block/sda/removable". And since /sys is part of the Linux ABI it should be a stable interface. The bigger question is if the data found there is reliable. I don't know. I do know some of the sysfs fields associated with the disks are not reliable (but the existence of the files are stable!). Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Sep 14, 2011 at 01:53:18PM -0400, Greg Freemyer wrote:
On Wed, Sep 14, 2011 at 1:33 PM, Greg KH <gregkh@suse.de> wrote:
On Wed, Sep 14, 2011 at 05:40:01PM +0200, Anders Johansson wrote:
On Wednesday 14 September 2011 10:53:42 Greg KH wrote:
If you want to determine if this really is a USB device or not, then you need to look elsewhere in the system, not in /dev.
Out of interest, what is the correct way to determine if a particular device is removable, with hal gone? Is it the DeviceIsRemovable property in DeviceKit/udisk?
Yes, I think it is.
Are you avoiding /sys for some reason?
It's easier to make a library call than to dig through sysfs yourself most of the time.
If not, I vote for it being "cat /sys/block/sda/removable".
Doesn't work well from within a .c program :)
And since /sys is part of the Linux ABI it should be a stable interface.
It should, as long as you properly handle symlinks and recover properly if the file is not present. That is why using a library for this is always easier than having to re-write that logic all the time.
The bigger question is if the data found there is reliable. I don't know. I do know some of the sysfs fields associated with the disks are not reliable (but the existence of the files are stable!).
I don't know if all disks properly tell their state as "removable" in this manner. Again, what would you call a USB->ATA disk controller device? The disk itself is not "removable" in that it thinks it is getting ata commands. Yet the fact that it is behind a USB connection makes the user think it is. And again, what about PCI hotplug disks? There are whole storage devices out there where you can yank out a disk at any point in time, so they are "removable" yet the disk itself has no idea it really is that. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 14 September 2011 22:51:43 Greg KH wrote:
Again, what would you call a USB->ATA disk controller device? The disk itself is not "removable" in that it thinks it is getting ata commands. Yet the fact that it is behind a USB connection makes the user think it is.
And again, what about PCI hotplug disks? There are whole storage devices out there where you can yank out a disk at any point in time, so they are "removable" yet the disk itself has no idea it really is that.
Look I just want to have USB devises to be shown with USB drive icon, as it is in the case of HAL. There is an algorithm for it but not working because the usb devices do not use the conventional ub* name. I still cannot understand why it is impossible to make USB devices to bear a special name like the CD/DVD ones do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Wed, 14 Sep 2011 23:30:22 +0400 schrieb Ilya Chernykh <anixxsus@gmail.com>:
Look I just want to have USB devises to be shown with USB drive icon, as it is in the case of HAL. There is an algorithm for it but not working because the usb devices do not use the conventional ub* name.
The algorithm is broken, at least if it depends on them being named ub* This is almost as broken as the networking stuff over 5 years ago that depended on wireless network interfaces having certain names.
I still cannot understand why it is impossible to make USB devices to bear a special name like the CD/DVD ones do.
It is not impossible, see below. It is not useful because the disk driver (the one sending the scsi commands to it) does not know / care on which bus type they are. But you can look that up easily in sysfs: susi:/tmp # l /sys/block/sd* lrwxrwxrwx 1 root root 0 Sep 14 21:33 /sys/block/sda -> ../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/ lrwxrwxrwx 1 root root 0 Sep 14 21:51 /sys/block/sdb -> ../devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1:1.0/host7/target7:0:0/7:0:0:0/block/sdb/ (I have no idea if it is a good idea to just check where the link points to and then decide that this is an USB bus, but that would be one way of doing it) You could also create a udev rule that renames drives on an usb bus to "ub*", but I would almost bet that that would break other things. You can of course fork the linux kernel and change the drivers, so that they do what you want. If I was in your situation, I would just fix the algorithm to detect drives correctly instead of depending on the device name. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Sep 14, 2011 at 11:30:22PM +0400, Ilya Chernykh wrote:
On Wednesday 14 September 2011 22:51:43 Greg KH wrote:
Again, what would you call a USB->ATA disk controller device? The disk itself is not "removable" in that it thinks it is getting ata commands. Yet the fact that it is behind a USB connection makes the user think it is.
And again, what about PCI hotplug disks? There are whole storage devices out there where you can yank out a disk at any point in time, so they are "removable" yet the disk itself has no idea it really is that.
Look I just want to have USB devises to be shown with USB drive icon, as it is in the case of HAL. There is an algorithm for it but not working because the usb devices do not use the conventional ub* name.
Because your algorithm is completely wrong. As proof of that, why not look at the HAL code for how it does the logic of detecting the drive type. As you are replacing the HAL code, it probably would be best if you copy how it works pretty identically in order to ensure that everything works the same.
I still cannot understand why it is impossible to make USB devices to bear a special name like the CD/DVD ones do.
I still can not understand why what we have previously explained has not been sufficient in order to explain this :) greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday, September 14, 2011 11:30 PM, "Ilya Chernykh" <anixxsus@gmail.com> wrote:
On Wednesday 14 September 2011 22:51:43 Greg KH wrote:
Again, what would you call a USB->ATA disk controller device? The disk itself is not "removable" in that it thinks it is getting ata commands. Yet the fact that it is behind a USB connection makes the user think it is.
And again, what about PCI hotplug disks? There are whole storage devices out there where you can yank out a disk at any point in time, so they are "removable" yet the disk itself has no idea it really is that.
Look I just want to have USB devises to be shown with USB drive icon, as it is in the case of HAL. There is an algorithm for it but not working because the usb devices do not use the conventional ub* name.
I'm no expert on this so I'm probably missing something here, but I know that with HAL being deprecated KDE, GNOME and XFCE have all switched to udev/udisks to do this (and it works perfectly in my experience on KDE4). Why not use udev in KDE3 as well? Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 15 September 2011 11:56:47 Tim Edwards wrote:
I'm no expert on this so I'm probably missing something here, but I know that with HAL being deprecated KDE, GNOME and XFCE have all switched to udev/udisks to do this (and it works perfectly in my experience on KDE4). Why not use udev in KDE3 as well?
Because there are only two backends there: the hal backend and the mtab/fstab backend. The letter being universal and working on any Unix-like system (I think an udev backend would be Linux only). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday, September 15, 2011 1:30 PM, "Ilya Chernykh" <anixxsus@gmail.com> wrote:
On Thursday 15 September 2011 11:56:47 Tim Edwards wrote:
I'm no expert on this so I'm probably missing something here, but I know that with HAL being deprecated KDE, GNOME and XFCE have all switched to udev/udisks to do this (and it works perfectly in my experience on KDE4). Why not use udev in KDE3 as well?
Because there are only two backends there: the hal backend and the mtab/fstab backend. The letter being universal and working on any Unix-like system (I think an udev backend would be Linux only).
udev is probably Linux only, but KDE4 and GNOME work on *BSD and other Unixes too. Why not just have kde3 use the same technologies as KDE4 and GNOME? On Linux that'd be udev, on other Unixes it'd be something else, eg. maybe devd on FreeBSD. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Sep 15, 2011 at 01:28:24PM +0200, Tim Edwards wrote:
On Thursday, September 15, 2011 1:30 PM, "Ilya Chernykh" <anixxsus@gmail.com> wrote:
On Thursday 15 September 2011 11:56:47 Tim Edwards wrote:
I'm no expert on this so I'm probably missing something here, but I know that with HAL being deprecated KDE, GNOME and XFCE have all switched to udev/udisks to do this (and it works perfectly in my experience on KDE4). Why not use udev in KDE3 as well?
Because there are only two backends there: the hal backend and the mtab/fstab backend. The letter being universal and working on any Unix-like system (I think an udev backend would be Linux only).
udev is probably Linux only, but KDE4 and GNOME work on *BSD and other Unixes too. Why not just have kde3 use the same technologies as KDE4 and GNOME? On Linux that'd be udev, on other Unixes it'd be something else, eg. maybe devd on FreeBSD.
udev and libdevattr is available for BSD already, and some BSD variations already use it, so there's no reason why all of them couldn't if they wanted to. Here's a link to the commit if proof is needed: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/3a3826b3871c8c2f480b... greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 11:18 AM, Ilya Chernykh <anixxsus@gmail.com> wrote:
On Tuesday 13 September 2011 18:22:40 Greg KH wrote:
It is obviously incorrect, if to follow the Lanana specification, and any intuitive logic. Why this driver uses SCSI names for USB devices?
Because USB storage devices are really just SCSI devices, look at the USB storage spec for details if you are curious.
Wow. On my system all disks except the DVD drive are4 shown as with sd* name. Does it mean the SATA drive is also a SCSI drive? I also have an IDE drive attached via a parallel cable, is it also a SCSI drive? This becomes ridiculous.
Libata was developed for 2.6. It should have been a from scratch full fledged driver. Instead they decided to take advantage of the SCSI exception handling stack. When 2.6 first came out most distros used /dev/hda etc. and the associated old drivers/ide kernel code. Over time most of the functionality of drivers/ide was migrated (or re-implemented) in libata. A couple years ago the linux kernel team made a decision to put drivers/ide into a maintenance only mode. It should no longer be getting new drivers or functionality. Obviously most general purpose distros are now using libata by default. Unfortunately libata is still under the scsi stack, so it gets the /dev/sdx style names. You can argue its a bug, but in reality it's a design decision that is way outside of the opensuse communities control.
There are different backends that use different methods. Currently KDE3 has two backends: a HAL backend that uses HAL api, and mtab/fstab backend that scans mtab table. HAL backend will be useless in a system without hal.
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
It is impossible to determine whether a given drive an USB drive or hard based on mtab only if the both use similar sd* name.
The name is not a API. You should be looking at /sys/block/sda. That directory is full of useful things. For instance /sys/block/sda/removable should contain a zero or one depending on the nature of the storage. And /sys/block/sda/queue/rotational should contain the rpms of a rotating disk, or zero (for unknown), or one (for solid state disk). Unfortunately the rotational file is not very accurate. I just checked on this workstation and my rotating disk is identified as solid-state per that field. Can't say I'm overly surprised.
> > > > Thus the mtab backend thinks about USB drives as of hard disks.
Lots of them are hard disks :)
Still this is incorrect, there in a "removable" device type that should be used. When using hal, the usb drives are shown with "flash drive" icon.
That's wrong then, fix HAL :)
This is completely correct. I insert a flash drive and see it as a flash drive.
It is actually interesting why USB devices are assigned SCSI-names, and should not they receive USB names.
No it isn't, it's been that way for over 10 years now, nothing new here at all
As I already said this contradicts at least the Lanana specification adopted in 2009. Even if this was the case for a long time, it obviously contradicts the modern specification.
Again, no, it does not, your USB device is really using the SCSI stack, so it is a SCSI device.
Do you have a prooflink?
I'm pretty sure that SCSI is actually a network stack based protocol. (ie. the standard 7 layer model). Much like TCP sits on IP sits on eithernet sits on cat5. USB is actually an official part of the SCSI stack I believe. So the commands that are transmitted over the USB cable are real SCSI commands, just as the packets that are transmitted over cat5 carry TCP packets. So USB being part of the SCSI stack is the correct and proper way to do it. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 22:46:04 Greg Freemyer wrote:
Unfortunately libata is still under the scsi stack, so it gets the /dev/sdx style names.
Why then the CD/DVD has different name if it uses the same stack?
It is impossible to determine whether a given drive an USB drive or hard based on mtab only if the both use similar sd* name.
The name is not a API. You should be looking at /sys/block/sda. That directory is full of useful things.
For instance /sys/block/sda/removable should contain a zero or one depending on the nature of the storage.
Thanks! This is very useful! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 4:39 PM, Ilya Chernykh <anixxsus@gmail.com> wrote:
On Tuesday 13 September 2011 22:46:04 Greg Freemyer wrote:
Unfortunately libata is still under the scsi stack, so it gets the /dev/sdx style names.
Why then the CD/DVD has different name if it uses the same stack?
I have no idea and I know a fair amount about libata. Sorry. If you really want to know, you will need to post to the libata mailinglist. "IDE/ATA development list" <linux-ide@vger.kernel.org> No subscription needed, just post away. They have a reply all policy so you should see any responses. Good Luck, Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Wed, 14 Sep 2011 00:39:39 +0400 schrieb Ilya Chernykh <anixxsus@gmail.com>:
On Tuesday 13 September 2011 22:46:04 Greg Freemyer wrote:
Unfortunately libata is still under the scsi stack, so it gets the /dev/sdx style names.
Why then the CD/DVD has different name if it uses the same stack?
Trying to use simple english: The SCSI storage stack has several "device types". One of them is the "SCSI-Harddrive", another one is the "SCSI-Opticaldisk". In the Linux kernel configuration, it's expressed like that: # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m so you get a compiled in driver "sd_mod", which is the driver for "SCSI-Harddrive" and a driver module "sr_mod" (which in turn depends on the generic "cdrom" driver) and that one is for SCSI-CDROM. They all talk SCSI, but they send different messages. It's a bit like TCP and UDP both using the IP protocol in networking. (Greg F. could probably explain this much better, but I think my inter- pretation is sufficient to understand the reasoning behind "sr" and "sd".) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Mittwoch, 14. September 2011, 16:56:02 schrieb Stefan Seyfried:
Why then the CD/DVD has different name if it uses the same stack?
Trying to use simple english:
The SCSI storage stack has several "device types". One of them is the "SCSI-Harddrive", another one is the "SCSI-Opticaldisk". [..] They all talk SCSI, but they send different messages. It's a bit like TCP and UDP both using the IP protocol in networking.
(Greg F. could probably explain this much better, but I think my inter- pretation is sufficient to understand the reasoning behind "sr" and "sd".)
Now _I_ understood it while before _I_ only accepted it as the way things are. Thank you Stefan/seife. -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 9/14/2011 10:56 AM, Stefan Seyfried wrote:
Am Wed, 14 Sep 2011 00:39:39 +0400 schrieb Ilya Chernykh<anixxsus@gmail.com>:
On Tuesday 13 September 2011 22:46:04 Greg Freemyer wrote:
Unfortunately libata is still under the scsi stack, so it gets the /dev/sdx style names.
Why then the CD/DVD has different name if it uses the same stack?
Trying to use simple english:
The SCSI storage stack has several "device types". One of them is the "SCSI-Harddrive", another one is the "SCSI-Opticaldisk".
In the Linux kernel configuration, it's expressed like that:
# # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m
so you get a compiled in driver "sd_mod", which is the driver for "SCSI-Harddrive" and a driver module "sr_mod" (which in turn depends on the generic "cdrom" driver) and that one is for SCSI-CDROM.
They all talk SCSI, but they send different messages. It's a bit like TCP and UDP both using the IP protocol in networking.
(Greg F. could probably explain this much better, but I think my inter- pretation is sufficient to understand the reasoning behind "sr" and "sd".)
Indeed, there are also many non-block devices that are reached via scsi, backplanes and hot-swap enclosures of course for the obvious starters, but also scanners and even terminal servers, thus sg* and other names. I don't mean usb looking like scsi, literally scsi. sr* is no mystery in that sense, although, a cdrom IS a block device not a scanner or a tty. He is right that if GKH's argument about consistency is to hold much water, optical media should be just yet another flavor of sd*, the fact that it's read-only and needs special handling to write should hardly matter, they come on all the same interfaces as all the other block devices, ide, sata, scsi, usb, parallel. But that just comes down to "you're right, it's inconsistent, go tell LKML". It still doesn't mean libata shouldn't be used or that there's anything especially confusing or wrong about the way usb drives are detected and named currently. Hardware is simply highly dynamic these days unlike in the past. "most other unix" simply make little or no attempt to have adapted to the current realities of hardware. At least nowhere near as much as Linux and Windows has. My "other unix" experience is SCO and FreeBSD and a little Solaris. It comes as no surprise to me and is not a new thing either, that there are certain assumptions I can safely make about mtab and /dev on sco that I can't on Linux, but it's only because SCO simply can't do or handle half of what Linux does in the first place. You have to reboot to add a drive to a sco box! You have to reboot to change a nics IP! (rare arcane theoretical exceptions excluded) There is a usb driver, barely, in the very last version, completely overhauled and changed in an update pack, and is possibly less consistent than Linux, certainly less flexible and less in line with actual usage. CHeck out the directions to usb hard drive: http://osr507doc.sco.com/en/HANDBOOK/USB_configuring.html A legacy-free system with only usb versions of serial, parallel, floppy drives, should those devices appear as funky new unpredictable usb names or as the ancient names that are hardcoded in countless commercial apps who no longer even have vendors to update them? Both answers make sense. I see nothing especially wrong about the way libata, usb, and sg are used. As with everything always, it could be improved, but it's hardly stupid or obviously all backwards or anything like that. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Wed, 14 Sep 2011 18:35:54 -0400 schrieb "Brian K. White" <brian@aljex.com>:
sr* is no mystery in that sense, although, a cdrom IS a block device not a scanner or a tty. He is right that if GKH's argument about consistency is to hold much water, optical media should be just yet another flavor of sd*, the fact that it's read-only and needs special handling to write
But it uses another "command set" or "protocol" (on top of scsi transport layer) than harddrives. ISTR that once I put in a DVD-RAM disk (DVD-RAM, in contrast to crap DVD-ROM is a random access writeable medium and all this is handled transparently by the drive's firmware, no need for magic incantations and dealing with strange tools), my DVD drive becomes a "normal" block device and I can access that dvd-ram via sd*, but I'd need to check if my memory serves me right. I think my "TCP vs UDP, both using the IP protocol but being different things" analogy was not too bad to explain the difference. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 15 September 2011 11:07:34 Stefan Seyfried wrote:
sr* is no mystery in that sense, although, a cdrom IS a block device not a scanner or a tty. He is right that if GKH's argument about consistency is to hold much water, optical media should be just yet another flavor of sd*, the fact that it's read-only and needs special handling to write
But it uses another "command set" or "protocol" (on top of scsi transport layer) than harddrives.
ISTR that once I put in a DVD-RAM disk (DVD-RAM, in contrast to crap DVD-ROM is a random access writeable medium and all this is handled transparently by the drive's firmware, no need for magic incantations and dealing with strange tools), my DVD drive becomes a "normal" block device and I can access that dvd-ram via sd*, but I'd need to check if my memory serves me right.
I have just checked. Put an UDF volume into the drive and it is still sr0.
I think my "TCP vs UDP, both using the IP protocol but being different things" analogy was not too bad to explain the difference. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Thu, 15 Sep 2011 13:28:09 +0400 schrieb Ilya Chernykh <anixxsus@gmail.com>:
I have just checked. Put an UDF volume into the drive and it is still sr0.
Not a UDF volume. A DVD-RAM medium. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 15 September 2011 16:54:56 Stefan Seyfried wrote:
I have just checked. Put an UDF volume into the drive and it is still sr0.
Not a UDF volume. A DVD-RAM medium.
I inserted CD-RAM formatted into UDF file system. It it available to direct write and any operation as a hard drive. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 18:22:40 Greg KH wrote:
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
It completely correctly follows the Lanana specification. How can I "correct" it further? It is how it realized in openSUSE is wrong - it does not respect the kernel's device naming policy. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Sep 13, 2011 at 07:54:35PM +0400, Ilya Chernykh wrote:
On Tuesday 13 September 2011 18:22:40 Greg KH wrote:
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
It completely correctly follows the Lanana specification. How can I "correct" it further? It is how it realized in openSUSE is wrong - it does not respect the kernel's device naming policy.
Then every single distro shipping today is "wrong" according to you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 September 2011 20:07:31 you wrote:
Also note that mtab/fstab backend is the most universal because any system no and in the future will have there tables, regardless whether it has udisks or other more complicated components.
But it sounds like the mtab/fstab backend is buggy. Please fix it :)
It completely correctly follows the Lanana specification. How can I "correct" it further? It is how it realized in openSUSE is wrong - it does not respect the kernel's device naming policy.
Then every single distro shipping today is "wrong" according to you.
This is not impossible, right? Because they use the same kernel and share the same bugs. The *BSD distros on the other hand, use the device names as intended. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (9)
-
Anders Johansson -
Brian K. White -
Greg Freemyer -
Greg KH -
Ilya Chernykh -
Jean-Daniel Dodin -
Ralf Lang -
Stefan Seyfried -
Tim Edwards