From: Patrick Mansfield <patmans@us.ibm.com>
To: Andries.Brouwer@cwi.nl
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net,
mdharm-kernel@one-eyed-alien.net, zwane@holomorphy.com
Subject: Re: IDs
Date: Tue, 7 Jan 2003 10:02:09 -0800 [thread overview]
Message-ID: <20030107100209.A15291@beaverton.ibm.com> (raw)
In-Reply-To: <UTC200301071055.h07At0T09202.aeb@smtp.cwi.nl>; from Andries.Brouwer@cwi.nl on Tue, Jan 07, 2003 at 11:55:00AM +0100
On Tue, Jan 07, 2003 at 11:55:00AM +0100, Andries.Brouwer@cwi.nl wrote:
> > But, we don't have to truncate, we should just allocate as many bytes as
> > we need, and store the information.
>
> > And, the sysfs name should not store the id.
>
> OK. It seems that we are in total agreement.
> Time for the next question.
>
> An id is constructed, that in many cases identifies something.
> How do you plan to use this? Is it already in use somewhere?
It's not in use in the main-line kernel.
I forgot to mention that I'm using the id in scsi mid-level multi-path
code, it has the same problem (the id is not always unique, plus other
major issues to deal with).
I'm not working on any device naming/persistence code, although I have
given thought to solutions. Any solution there might apply to multi-path
usage. But the multi-path cannot easily be moved to user space until we
have complete user level scsi scanning.
Is anyone currently writing device name solutions based on the scsi id?
> The sysfs tree does not contain device nodes.
> Do you plan a user space utility that figures out that
> the ID "SHP CD-Writer+ 8200 [" belongs to /dev/hdd
> which also is /dev/sr0?
With the current code, any utility would be scsi specific (it could only
name scsi devices based on an id, others would get a default name), so it
would only cover /dev/sr0. I don't know much about IDE capabilities.
> The id is not suitable as a user space name. Moreover,
> it is a heuristic only, and user space needs unambiguous names.
If we had a complete white/black list of devices with/without a unique id,
there would be no ambiguity. Such a list could be generated by asking the
user/administrator each time an unknown device is added to the system (or
have a safe default); we could also have a white/black somewhere (for use
from user space), much like we have with scsi_static_device_list in
scsi_scan.c today.
A user level white/black list is also useful for scanning, especially for
user level scanning, and for kernel scanning if we can access it before
starting the scan (via ramdisk at boot time).
> What user space names do you want to use?
Maybe have a configurable starting point (like /devnames, maybe
something that does not collide with /dev, perhaps we can generate a
/dev matching exactly what we have today), much like a mount point, or
like devfs. I don't know of any good reasons for a file system.
In any case, right now we should fix the scsi sysfs name, and add (and not
truncate) a uid to scsi_device.
-- Patrick Mansfield
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
WARNING: multiple messages have this Message-ID (diff)
From: Patrick Mansfield <patmans@us.ibm.com>
To: Andries.Brouwer@cwi.nl
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net,
mdharm-kernel@one-eyed-alien.net, zwane@holomorphy.com
Subject: Re: IDs
Date: Tue, 7 Jan 2003 10:02:09 -0800 [thread overview]
Message-ID: <20030107100209.A15291@beaverton.ibm.com> (raw)
In-Reply-To: <UTC200301071055.h07At0T09202.aeb@smtp.cwi.nl>; from Andries.Brouwer@cwi.nl on Tue, Jan 07, 2003 at 11:55:00AM +0100
On Tue, Jan 07, 2003 at 11:55:00AM +0100, Andries.Brouwer@cwi.nl wrote:
> > But, we don't have to truncate, we should just allocate as many bytes as
> > we need, and store the information.
>
> > And, the sysfs name should not store the id.
>
> OK. It seems that we are in total agreement.
> Time for the next question.
>
> An id is constructed, that in many cases identifies something.
> How do you plan to use this? Is it already in use somewhere?
It's not in use in the main-line kernel.
I forgot to mention that I'm using the id in scsi mid-level multi-path
code, it has the same problem (the id is not always unique, plus other
major issues to deal with).
I'm not working on any device naming/persistence code, although I have
given thought to solutions. Any solution there might apply to multi-path
usage. But the multi-path cannot easily be moved to user space until we
have complete user level scsi scanning.
Is anyone currently writing device name solutions based on the scsi id?
> The sysfs tree does not contain device nodes.
> Do you plan a user space utility that figures out that
> the ID "SHP CD-Writer+ 8200 [" belongs to /dev/hdd
> which also is /dev/sr0?
With the current code, any utility would be scsi specific (it could only
name scsi devices based on an id, others would get a default name), so it
would only cover /dev/sr0. I don't know much about IDE capabilities.
> The id is not suitable as a user space name. Moreover,
> it is a heuristic only, and user space needs unambiguous names.
If we had a complete white/black list of devices with/without a unique id,
there would be no ambiguity. Such a list could be generated by asking the
user/administrator each time an unknown device is added to the system (or
have a safe default); we could also have a white/black somewhere (for use
from user space), much like we have with scsi_static_device_list in
scsi_scan.c today.
A user level white/black list is also useful for scanning, especially for
user level scanning, and for kernel scanning if we can access it before
starting the scan (via ramdisk at boot time).
> What user space names do you want to use?
Maybe have a configurable starting point (like /devnames, maybe
something that does not collide with /dev, perhaps we can generate a
/dev matching exactly what we have today), much like a mount point, or
like devfs. I don't know of any good reasons for a file system.
In any case, right now we should fix the scsi sysfs name, and add (and not
truncate) a uid to scsi_device.
-- Patrick Mansfield
next prev parent reply other threads:[~2003-01-07 18:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-07 2:19 IDs Andries.Brouwer
2003-01-07 3:15 ` IDs Patrick Mansfield
2003-01-07 10:55 ` IDs Andries.Brouwer
2003-01-07 17:07 ` IDs Greg KH
2003-01-07 17:07 ` [linux-usb-devel] " Greg KH
2003-01-07 18:02 ` Patrick Mansfield [this message]
2003-01-07 18:02 ` IDs Patrick Mansfield
-- strict thread matches above, loose matches on Subject: below --
2003-01-07 18:54 IDs Andries.Brouwer
2003-01-07 18:54 ` IDs Andries.Brouwer
2003-01-07 20:02 ` IDs Patrick Mansfield
2003-01-07 0:00 IDs Andries.Brouwer
2003-01-07 0:00 ` IDs Andries.Brouwer
2003-01-07 2:13 ` IDs Patrick Mansfield
2001-09-29 19:00 IDs Tim Jansen
2001-09-29 19:56 ` IDs Vojtech Pavlik
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=20030107100209.A15291@beaverton.ibm.com \
--to=patmans@us.ibm.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mdharm-kernel@one-eyed-alien.net \
--cc=zwane@holomorphy.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.