Re: Adieu, Fedora

On 06/14/2011 11:43 PM, Joe Zeff wrote:
On 06/14/2011 03:01 PM, Marcus D. Leech wrote:
Which of those four items do you think should "show up automatically"
when you plug in the drive?

All four seems reasonable. Again, however, your missing my main
complaint. It's not that the USB services don't report the label, it's
that the devs claim falsely that it does and refused to look at the
proof that they are wrong. Simply telling me "shut up and go away!"
isn't a rational response; it's more like an ostrich sticking its head
in the sand and hoping that the problem will go away.

If you mean the threads "Simple USB/Linux question" and "more on flash drives"
from a linux-usb a couple of years back I don't think I share your
interpretation of the responses you received.

The statement "the kernel drivers make all the data available to the window
manager, and it decides how to show the device." /includes/ data that is stored
"inside" the device (when it is a block device like a USB mass storage device).
This is also what was meant with the comment "It's probably pulling the
information directly from the device, or via udev.".

The kernel provides basic standardised hardware properties directly via the
sysfs virtual file system. This includes the attributes listed above (Vendor,
Product etc.) - in short, anything that shows up in the output of "udevadm info
-a" for a given piece of hardware.

In modern Linux distributions programs like udev and udisks call out to
lower-level userspace programs like scsi_id, blkid etc. to retrieve additional
information about what is stored on the device. These programs open the device
from userspace and read whatever information they need to via I/O calls, ioctl
commands etc.

This includes the filesystem-specific label, UUID and other metadata - Linux has
long had a policy of handling this type of data in userspace and for good
reasons (it's part of the UNIX heritage of separating mechanism from policy -
the kernel provides the mechanisms to access the information but applies no
particular policy as to what to do with it or how to present it).

Partition tables are one ugly exception to this but there have even been
discussions in recent years (and at least one patch set) to remove those from
the kernel and handle them in user space instead.

Reading, reporting and interpreting labels are not the job of the USB drivers or
their maintainers. The right people to help really are the maintainers of the
user space hardware abstraction subsystems and the various desktop environments.


users mailing list
To unsubscribe or change subscription options:

Relevant Pages

  • Re: slow USB printing in 2.6
    ... > Ever since I upgraded the kernel to 2.6, USB support has been ... I think that the kernel-developers will need your report. ...
  • Re: 8-current USB patches available for testing (set #020)
    ... Diff between USB P4 and 8-current is available from below. ... and report back if there are any issues. ... order to use this patch? ... You should rebuild kernel + world. ...
  • Re: Hangup on USB mass device
    ... so it's recognized as a USB 1.0 device. ... debugging kernel. ... page fault while in kernel mode ... you should report it to the -usb list as well. ...
  • Re: USB drivers
    ... :> Can someone give a sample what the kernel should report when it discovers an ... Recompile your kernel with USB support. ...
  • Several OOPSes in net/sched/sch_generic.c, kernel/softirq.c (and other places)
    ... I have witnessed several kernel oopses in a vanilla 2.6.32 kernel of different patch levels. ... As I have no idea how I can trigger this oops -- it just happens after a few hours of running -- I'll list what I'm using the machine for: it's running Debian squeeze with a custom built kernel, vanilla (.config attached). ... A WLAN AP is running over the USB wireless stick, which is bridged with the LAN side of the one NIC. ... # Device Drivers ...