From: James Finnall <James@Finnall.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Identical USB devices rules
Date: Thu, 03 Aug 2006 12:56:46 +0000 [thread overview]
Message-ID: <200608030856.46951.James@Finnall.net> (raw)
In-Reply-To: <200608021809.13802.James@Finnall.net>
Thank you for the response. From the udevinfo returned from the units they
are identical, even the serial number. Of course, the hard disk is most apt
to change every time I use the device so that info is not of any value to me.
The only thing I found I could use here was to write two rules and then select
them by the USB ID field, ID="3-2" and ID="3-4". At present that seems to
work OK on my system. I only have three USB ports and one is used for a USB
mouse. So I have to use the other two for operations like this. So I think
these rules should be OK. So my rules lare ike below now.
ID="3-2",SYSFS{idVendor}="0402", SYSFS{idProduct}="5642", NAME="disk/drv%n"
ID="3-4",SYSFS{idVendor}="0402", SYSFS{idProduct}="5642", NAME="disk1/drv%n"
Not really a good way to identify, because I think it so system specific on
the hardware support. To allow identical devices to be distinguished
differently only by the actual port it is connected removes the true hot plug
and play operation. Ideally, it shouldn't matter which port it is connected
or at least it should be invisible to the user creating the rules. On my
system each port is both USB level 1 and USB level 2. These are different
controllers and are on different busses. The "3" in ID="3-2" indicates it
is on buss 3 from what I am able to determine. My mouse is only USB level 1
and it is on USB buss "2". The rules have to then be created for every
device multiple times if they are identical. For my instance, ideally, the
first drive connected to any port should get the first assignment. Then the
2nd drive connected gets the next assignment but within the single rule.
But with the rules above the drive that is connected to that specific port
will get the assigned devices, regardless of whether it is first or not.
Now, that may not always be undesirable either. Like my circumstances
cloning a hard disk, I think I actually prefer the method above. That way I
know which drive is the source drive of the operation.
Thank you once again for your consideration.
James
On Thursday 03 August 2006 03:38, Kay Sievers wrote:
> On Wed, 2006-08-02 at 18:09 -0400, James Finnall wrote:
> > New to the list and searched the archives some but unable to locate
> > something on identical hotplug devices for writing rules. I am running
> > udev and I had a custom rule for an external drive enclosure as follows:
> >
> > SYSFS{idVendor}="0402", SYSFS{idProduct}="5642", NAME="disk/drv%n"
> >
> > This works as desired for either of my devices that are identical when
> > only one is attached. But today I had a need to clone one drive to
> > another using both devices at the same time. I found that udev assigned
> > the device assignments to the 2nd drive unit as the first drive.
> >
> > The kernel originally used /dev/sde and /dev/sdf for each of the drives
> > when they were connected. And of course these could change depending on
> > what else may be connected at any given time by USB or IEEE1394. Being
> > unable to identify them separately in a rule to be sequential, I could
> > only remark out the rule above and then proceed with the kernel names
> > that were assigned.
> >
> > Is there a way to sequentially assign the drives using the name
> > convention above as in /dev/disk1/drv%n and /dev/disk2/drv%n when using
> > multiple devices that are identical?
>
> Almost all recent distros ship the persistent disk links maintained by
> udev which create /dev/disk/by-{id,label,uuid,path} directories and put
> symlinks in there. If you clone disks you copy uuid and label, which
> breaks by-label and by-uuid, but by-path should still work. If your
> drive enclosure is not one of the real cheap ones, you get a serial
> number there, which should make by-id work.
>
> Kay
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
> _______________________________________________
> Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2006-08-03 12:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-02 22:09 Identical USB devices rules James Finnall
2006-08-03 7:38 ` Kay Sievers
2006-08-03 12:56 ` James Finnall [this message]
2006-08-03 14:15 ` Kay Sievers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200608030856.46951.James@Finnall.net \
--to=james@finnall.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).