On Tuesday, September 13, 2011 01:42:39 PM Sascha Peilicke wrote:

On Tuesday 13 September 2011 14:32:21 Ilya Chernykh wrote:

...

What's the policy regarding games in openSUSE?

Submit whatever you're willing to maintain.

...

Should they go to Factory or just stay in the games repository?

In the past it seemed 'stay in games', altough this never made much sense. Makes sense to me. I don't know what games there really are, so when they are in one repo, I now know that all those are games. Keep games in the games repo I say... at least until AppStream is available. -- 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:05:40 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"?  :)

Why not? Anyway the root file system cannot be unmounted.

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"?

They are internal drives, even if hot-pluggable, I would not consider them 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.

The document says ub* is reserved for USB and sd* is for SCSI devices. Am I wrong?

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*.  

Does it mean this should not be corrected ever?

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.

I am talking not about past but about future and correctness.

...

By the way, DVD and CD drives still called sr*.

Sorry, you are correct, but they are still using the scsi subsystem.

So using the SCSI subsystem does not necessary imply usage of sd* name.  

And note, your USB dvd drive also uses sr*.

That's good. Why USB removable drive cannot use ub* then? -- 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:41 AM, Ralf Lang wrote:

Am Dienstag, 13. September 2011, 18:28:22 schrieb Ilya Chernykh:

...

On Tuesday 13 September 2011 20:05:40 you wrote:

...

...

By the way, DVD and CD drives still called sr*.

Sorry, you are correct, but they are still using the scsi subsystem.

So using the SCSI subsystem does not necessary imply usage of sd* name.

...

And note, your USB dvd drive also uses sr*.

That's good. Why USB removable drive cannot use ub* then?

Wrong thread. But really, I think you are wrong this time. btw how does KDE4 handle it?

KDE4 uses udev. More specifically, solid, KDE4's hardware abstraction layer, use udev. KDE4 applications then talk to solid. So when solid switched from hal to udev, the change was mostly (if not completely) transparent to applications. Solid was new for KDE 4, and was aimed specifically at making changes like the switch from hal to udev easier. As far as I am aware, KDE 3 has no such abstraction layer, so doing the change would require more substantial changes to more parts. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday, September 15, 2011 6:51 PM, "Ilya Chernykh" wrote:

On Thursday 15 September 2011 14:29:28 todd rme wrote:

...

Solid was new for KDE 4, and was aimed specifically at making changes like the switch from hal to udev easier. As far as I am aware, KDE 3 has no such abstraction layer, so doing the change would require more substantial changes to more parts.

KDE3 has mediamanager which can have different backends, one being hal backend and the other being fstab/mtab backend

Here's the source-code to the mediamanager fstab backend if anyone's interested: http://websvn.kde.org/branches/KDE/3.5/kdebase/kioslave/media/mediamanager/f... If you have a look at FstabBackend::guess you can see it tries all sorts of hacks and tricks based on the mountpoint, fs type or device node path to try to determine the type of device. And begins with the warning "// Guessing device types by mount point is not exactly accurate...". Interesting, but I'd be amazed if this even worked properly when KDE3 was current. Plus, pretty much everyone would've used the HAL backend as that's what the distro's provided. And the code hasn't been touched for 5 years now.. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Ok, but i thought the problem was the information you need just doesnt exist in mtab? I would look at udev. Tim Ilya Chernykh schrieb:

On Thursday 15 September 2011 19:36:13 Tim Edwards wrote:

...

...

...

Solid was new for KDE 4, and was aimed specifically at making changes like the switch from hal to udev easier. As far as I am aware, KDE 3 has no such abstraction layer, so doing the change would require more substantial changes to more parts.

KDE3 has mediamanager which can have different backends, one being hal backend and the other being fstab/mtab backend

Here's the source-code to the mediamanager fstab backend if anyone's interested:

http://websvn.kde.org/branches/KDE/3.5/kdebase/kioslave/media/mediamanager/f...

Recently I made a huge patch to it which can be found in KDE:KDE3 repository: https://build.opensuse.org/package/view_file?file=mtab-reenable.patch&package=kdebase3&project=KDE%3AKDE3

Without this patch the picture is incomplete.

...

If you have a look at FstabBackend::guess you can see it tries all sorts of hacks and tricks based on the mountpoint, fs type or device node path to try to determine the type of device. And begins with the warning "// Guessing device types by mount point is not exactly accurate...".

Interesting, but I'd be amazed if this even worked properly when KDE3 was current. Plus, pretty much everyone would've used the HAL backend as that's what the distro's provided. And the code hasn't been touched for 5 years now..

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday 15 September 2011 20:28:25 Tim Edwards wrote:

Ok, but i thought the problem was the information you need just doesnt exist in mtab? I would look at udev.

Yes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org