Re: The state of hotpluggable drives and devices....

Marc Duerner <[email protected]> Sat, 1 Jan 2005 14:19:12 +0100
Newsgroups gmane.linux.arklinux.devel
Message-ID <[email protected]>
Hello,
Bero mentioned the problem before but I hadn't have the time nor a device to 
work on it. 
If you want to fix it you have to look at PSI, our ark linux harware library 
(see SVN). The PartitionTable is being read out in HardDisk.h/.cpp.

You will have to look at the first 512 bytes of your device which is the mbr 
or the first partition record. The first 446 (0x1be) bytes can contain a 
program, while the last 66 bytes contain the partition table and a two byte 
signature (0x55aa for msdos). 
Under MsDos style a partition table entry is 16 bytes long( thus (4*16) + 2 = 
66). 
It would be helpful to know what your device shows.

Marc

On Saturday 01 Jan 2005 05:20, you wrote:
> Over Chirstmas I recieved a portable MP3 Player (MPIO FL300 www.mpio.com)
> and had sucess getting it working with Ark, however there are a few
> caveats:
>
> PROBLEM:
>
> Caveat #1: Improper handling of the device.
>
> This device is not partitioned. In other words, it's read like a single
> block device without partition signifiers. Currently, when I plug this
> device in to my front USB ports on my system, hotplug attempts to create a
> desktop icon and entries in /etc/fstab, but since it doesn't think that
> block devices should be using the whole disk, creates four icons on the
> desktop ( sdX1-4 ), and since it cannot be bound to any of these devices,
> hotplug cannot mount it.
>
> Caveat #2: Automated handling of /etc/fstab eats hand edited entries.
>
> Due to the problem detailed above, I hand entered my device into my
> /etc/fstab to mount the drive. Fun part comes in when I _remove_ the device
> from my computer; it deletes the entry I had HAND ENTERED! While Ark is
> aiming to be a desktop OS, we need to remember it's a UNIX-like OS. If I
> wanted changes I had made to be wiped out, I'd still be on Windows dealing
> with it's who-do magic it does on the Registry. For the moment, I digress,
> since the solution that I have at the end of the email will cover this.
>
> Caveat #3: Creation of unwanted desktop icons.
>
> I'm pretty particular about what is and is not on my desktop. Additionally,
> I am very exacting of my icon layout. While the icon layout is a KDE bug
> (one that was voted to death and is resolved for KDE 3.4), teh inclusion of
> icons and removal of the aforementioned icons is not something I'm thrilled
> with. For this reason I disabled the auto insertion system, since it too
> adds unneeded icons to my desktop. The solution at the end of this mail
> will address this as well.
>
> Caveat #4: Current solution does not integrate with KDE devices:/
> kio-slave.
>
> By default, the devices:/ kio-slave is disabled in Ark. The reason for this
> is that our current tools do not properly integrate with it. The reason I
> like having it turned on is to allow for three reass:
>
> 	1) easy mounting of devices via rmb.
> 	2) persistant device icons for block devices that will be used frequently,
> 		eliminating confusion.
> 	3) ease of access to mount points.
>
> Caveat #5: Poorly named mount points.
>
> While /etc/[hdXX|sdXX] is fine for IDE, SCSI, and USB hard disk devices,
> they aren't that useful for flash, mp3 players, and cameras. good practice
> would be to name the mount point after the device's name or function.
>
> SOLUTION:
>
> While the issues that I have with our hotplug system are annoying as hell,
> they are fixable. The solution for this is 2 kcms, one that handles the
> behaviour of the graphical portions of the handling of devices, another for
> fstab handling, additional UIs for requesting the behaviour at mount of the
> device, hacking the devices:/ kio-slave to do this integration, and adding
> my player to the hardware list with proper handling code.
>
> The first kcm needs to allow the user to exempt items from addition and
> removal from the filesystem table. A compromise is addition of special tags
> in the /etc/fstab to set segments in it as immutable. The second kcm needs
> to be able to set the behaviour of our hotplug system to either enable or
> disable the creation of desktop icons. Additionally, the second kcm needs
> to allow the user to be prompted at hotplug event to make the change
> perminent or whether it should revert after each unplug.
>
> The creation of the icons should be done through the devices:/ kio-slave
> this way it is registered and properly handled for the services:/ tree in
> the filemanager mode of Konqueror. The change of naming the mount after the
> device model name makes it easier to find the mount point in the /mnt
> directory since users don't know what hdXX or sdXX mean, but they do know
> things like MPIO_FL300.
>
> Finally, the information about my device:
> mpio FL300 mass storage needs detected automatically and mounted at
> mpio-fl300.
>   This device uses either the ub or the usb-storage driver and mounts on
> the ubXX or sdXX device nodes.
>   Vendor ID: 0x2735
>   PID:       0x100a
>   USB 1.10 device.