Re: [PATCH] /proc/scsi/map

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Kurt Garloff wrote:
> >
> > I really despise this.
>
> Thanks for your feedback.

You're too polite for your own good ;)

> Actually, I think you want to address a different problem than I want to.
>
> I do believe that the scsi subsystem does not expose enough information for
> many things.
>
> Look at /proc/scsi/scsi: The information is useful for the reader who wants
> to know what devices he has and were found by the SCSI subsystem.

I would rephrase that as "the information is only useful to find devices
found by the SCSI midlayer".

And my point is that you don't make it any better. Your patch perpetuates
this lopsided world-view that people should care. THAT is the fundamental
part that I don't like, because it drags us down for the future.

And in the end, if that is the case, it doesn't _help_ if it is "useful"
or not from a maintenance standpoint. From a maintenance standpoint, a
SCSI-only interface is a total horror.

I will bet you that there are more IDE CD-RW's out there than there are
SCSI devices. The fact that people use ide-scsi to write to them is a
hopefully very temporary situation, and the command interface is going
to move to a higher layer.

At which point your SCSI-centric world-view now became a total failure, as
it no longer shows up most of the devices that can write CD's or DVD's any
more.

Sure, it will still continue to show "what devices were found by the SCSI
midlayer". But user applications will have to scan other stuff, and find
the IDE-specific stuff, and then whatever else is out there.

See the problem?

If, on the other hand, you try to take the bull by the horns and realize
that the notion of "searching for devices" has nothing to do with SCSI at
_all_, you may find yourself with more work on your hands, but on the
other hand, wouldn't it be just so _nice_ to be able to do

	find /devices -name cd-rw

to find all cd-rw's in the system? Does it work that way now? Absolutely
not. But most of the infrastructure is actually there today. Wouldn't it
be _nice_ if after the CD-writing app has found all cd-rw's, it just opens
them, and the kernel will automatically open the right device (whether it
is a scsi-generic one or a IDE one)?

(No, I'm not serious about the "cd-rw" name itself, I'm just making a
simple example).

> And completely useless for any program that wants to find a scanner,
> CD-Writer, ... as there is no connection to the high-level drivers attached
> to them.

I'm not disputing that.

However, I _am_ disputing that this should be done in some SCSI-centric
way that works for SCSI but nothing else.

When I want to find a CD-ROM, I don't want to worry about whether it is
IDE or SCSI. I would

> But I still think the SCSI subsystem should report which SCSI (low-level)
> device is mapped to what high-level driver.
> Would you accept a patch that adds a line like
>
> Host: scsi3 Channel: 00 Id: 12 Lun: 00
>   Vendor: IBM      Model: DPSS-336950N     Rev: S84D
>   Type:   Direct-Access                    ANSI SCSI revision: 03
>   Attached drivers: sg12(c:15:0c) sdf(b:08:50)
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to /proc/scsi/scsi ?

That would be less offensive to me if only because it doesn't introduce a
_new_ interface that is SCSI-only, it only extends on an old one. It makes
no _technical_ difference, but I'd rather extend an old broken interface
than introduce a totally new broken interface.

> >  - is limited to a (arbitrary) subset of the disks in your system
>
> You mean all disks driven by the SCSI subsystem, right?

Yes. In particular, you miss the great majority of disks that way (IDE),
and you even miss SCSI disks that are behind controllers where the driver
writer refused to use the mid-layer.

For CD burning, you may be of the opinion that everything - including IDE
- _has_ to be SCSI layer anyway (because that is how it is right now), but
that is not going to be the case all that much longer, I hope.

> >  - has completely bogus information about "location" that has nothing to
> >    do with real life, yet pruports to be an "address" even though it
> >    obviously isn't.
>
> The CBTU tuple uniquely addresses a SCSI device in a running system.

Yes, but that's not enough. Other people are still asking for physical
location, so let's try to fix two things with _one_ generic interface that
is at least agnostic to how a device is connected to the kernel..

		Linus

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:

> Yes, but that's not enough. Other people are still asking for physical
> location, so let's try to fix two things with _one_ generic interface that
> is at least agnostic to how a device is connected to the kernel..


First and foremost please allow me to state that I support
entierly the view of Linus that we should try to be as much
as possible device type agnostic for generic functionality
like detection of partitions on block devices. Thats all what
operating systems are about: abstraction of hardware interfaces.
But:

1. There was the mistake of using different major numbers
for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).

2. Then came devfs along and promised to slove this problem.
    But people still complained about not beeing ablve to boot, after
    I changed the registration name for IDE devices from "ide" to "ata".
    This showed nicely that devfs doesn't cut it. It's useless for
    the purpose of unification of access methods apparently.

3. Now comes driverfs, which is basically a Solaris driver tree clone and
    *repeats* the same errors as 1. and 2.:


  ./
./bus
./bus/usb
./bus/usb/drivers
./bus/usb/devices
./bus/usb/devices/002001
...
./bus/usb/devices/001000
./bus/pci
./bus/pci/drivers
./bus/pci/drivers/parport_pc
..
./bus/pci/drivers/usb-uhci-hcd
./bus/pci/drivers/e100
./bus/pci/devices
./bus/pci/devices/00:0c.1
...
./bus/pci/devices/00:00.0

1. The /drivers information is useless. modutils are maintining they
own information. For some jet unknow reason they manage to
maintain te hierarchy entierly in user space.

The bus suffix. is useless for any purpose I can imagine.
Which kind of view is the above supposed to present?

./root

2. What is this root prefix good for?!
./root/pci0

3. Solaris is separating the name and enumeration part by @ for
good reaons.

./root/pci0/00:0c.1
./root/pci0/00:0c.1/resources

4. resources? What is the semantics of this supposed to be?
IO ranges, memmory mappings? Whatever. This is jet another
ASCI view for data which is too specific and should be only
maintained by the drivers itself internaly as it is.
Since it's not used now it will open jet another room
for arbitrary formating and random useless entires problems in the future.
Much like the mess in /proc only repeated for every single device on the
system.

./root/pci0/00:0c.1/irq

5. This is showing that the resources file above is useless, becouse
I would rather love to consider irq as a resource.

./root/pci0/00:0c.1/power
./root/pci0/00:0c.1/name

6. The /name is entierly redundant logically to the fact that we
have already a unique path to the device. For "pretty" printing
we have userspace. For PCI it's for example repeating the
ID info found already by lspci.

./root/pci0/00:07.2/usb_bus

7. What is the _bus? suffix good for? How does this releate
to the /bus hierarchy?

./root/pci0/00:07.2/usb_bus/00

9. Contrary to PCI we enumerate the busses apparently
by one dir level and not a suffix on the usb prefix.

./root/pci0/00:07.1/ata@00
./root/pci0/00:07.1/ata@00/sd@0,0
./root/pci0/00:07.1/ata@00/sd@0,0/power
./root/pci0/00:07.1/ata@00/sd@0,0/name
./root/pci0/00:07.1/ata@00/power
./root/pci0/00:07.1/ata@00/name

Here I'm trying to fit the whole in some kind of
physical view. I did sneak in the sd instead of
hd in the futile hope that SCSI will pick up the same
name. And I buy in to the idea of separating
the enumeratin for the naming by a @.
This way one has only to enumerate the
dir only and no room for possible ambiguity is present.
But it was entierly behind me how to fit this
in to the sheme other sd@4,0:h,raw
OS-es are using. And finally how would one fit this in to the
partitioning shemes? For the system aprtitions are simply
block devices hanging off the corresponding block device.

However we can see that the driver filesystem is
inconsistant on the kind of enumeration it should
provide. See the colon in sd@0,0 and the whole subdir
crazyness... So do we distingish different devices by a subdir?
Or do we do it by an unique enumeration suffix?

And last but not least: I still don't see any kind
of abstraction there which would allow to easly enumerate
for example all disks in the system.

However a simple major number range for disks 1 to 16000 would
be ideal. And I bet that at some (not too distant) day we will
simple have to reassign those numbers and be done.

Really people please let you inspire:

./pci@1f,4000/scsi@3/sd@9,0:f
./pci@1f,4000/scsi@3/sd@9,0:h,raw
./pci@1f,4000/scsi@3/sd@a,0:a
./pci@1f,4000/scsi@3/sd@a,0:b
./pci@1f,4000/scsi@3/sd@a,0:c
./pci@1f,4000/scsi@3/sd@a,0:a,raw
./pci@1f,4000/scsi@3/sd@a,0:b,raw

And just lets avoid the mistakes in the above.
I love the ,raw part for example instead of some
root mapping to completely different major numbers.



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] /proc/scsi/map

[James Bottomley]

dalecki@evision-ventures.com said:
> 1. There was the mistake of using different major numbers for SCSI and
> IDE/ATAPI devices. (disk and CD-ROM are the most striking). 

Don't confuse major numbers (which are really a kernel internal thing) with 
names.  Major numbers serve a very useful purpose in allowing quick device 
driver identification.  It would be an unhappy state of affairs if we had to 
parse both the major and minor numbers extensively just to identify the device 
driver to handle the request.  There's no reason why we can't use a consistent 
naming scheme for all CD-ROMs and yet have them using different major numbers.

One of the advantages of driverfs, I think, is that it separates the device 
name from a static entry in /dev which is tied to a major/minor number.

> 6. The /name is entierly redundant logically to the fact that we have
> already a unique path to the device. For "pretty" printing we have
> userspace. For PCI it's for example repeating the ID info found
> already by lspci. 

The /name is useful in the enterprise for persistent device identification.  
Leaves in the device tree can move as boxes are regconfigured.  The name entry 
helps you find your leaf again when this happens.  It also helps you find the 
same storage in a cluster regardless of the device driver or storage 
connection method.

> And last but not least: I still don't see any kind of abstraction
> there which would allow to easly enumerate for example all disks in
> the system. 

Doesn't this depend on the semantics provided in the device node (leaf)?  If 
you had a way of identifying disk devices (say from an empty type=disk file) 
then you could do a simple find to list all the disks in the system regardless 
of being SCSI, IDE, SSA etc.

James

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, James Bottomley wrote:
>
> > And last but not least: I still don't see any kind of abstraction
> > there which would allow to easly enumerate for example all disks in
> > the system.
>
> Doesn't this depend on the semantics provided in the device node (leaf)?  If
> you had a way of identifying disk devices (say from an empty type=disk file)
> then you could do a simple find to list all the disks in the system regardless
> of being SCSI, IDE, SSA etc.

Right now, the _biggest_ problem with driverfs is that it only does the
infrastructure, and precious little of the "real work".

For example, to be useful, every driver that knows about disks should make
sure they show up with some standard name (the old "disk" vs "disc" war
;), exactly so that you _should_ be able to do something like

	find /devices -name disk*

and be able to enumerate every disk in the whole system.

Of course, this is also the kind of meta-information that driverfs can
give "for free", ie since the kernel basically knows it is a disk, the
kernel can also directly expose the relationship of "these are all the
disks I know about". Ie again

	"kernel device relationship" == "driverfs"

which means that it should be fairly trivial to just do

	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
	               disk1 -> ../../pci0/00:02.3/usb_bus/001000/dev1

the same way that Pat already planned to do the mappings for network
devices in /devices/network/eth*.

Is this done? No. But is it fundamentally hard? Nope. Useful? You be the
judge.  Imagine yourself as a installer searching for disks. Or imagine
yourself as a initrd program that runs at boot, setting up irq routings
etc before the "real boot".

			Linus

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:

> For example, to be useful, every driver that knows about disks should make
> sure they show up with some standard name (the old "disk" vs "disc" war
> ;), exactly so that you _should_ be able to do something like
> 
> 	find /devices -name disk*

Not good. find /devices -name "/sd@* -- will be unambigious.
There are good reaons they do it like they do on the "other unix OS"...

> and be able to enumerate every disk in the whole system.

> 
> 	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
                  ^^^^^^^^^^ You notice the redundancy in naming here :-).

> 	               disk1 -> ../../pci0/00:02.3/usb_bus/001000/dev1
> 
> the same way that Pat already planned to do the mappings for network
> devices in /devices/network/eth*.

Boah the chierachies are already deep enough. /devices/net/eth@XX
will cut it.

> Is this done? No. But is it fundamentally hard? Nope. Useful? You be the
> judge.  Imagine yourself as a installer searching for disks. Or imagine
> yourself as a initrd program that runs at boot, setting up irq routings
> etc before the "real boot".

Yes but again the most content files found there are already inventing
interfaces on the heap. /name /irq /resources /power this will end the same
as similar attempts ended already - in a mess.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Martin Dalecki wrote:
> >
> > 	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
>                   ^^^^^^^^^^ You notice the redundancy in naming here :-).

I'd rather have redundancy than have horrible names like just "0", thank
you very much.

It takes up no space, all the dentries are virtual anyway, and a dentry
embeds the storage for the first n characters (n ~16 or something like
that).

> Boah the chierachies are already deep enough. /devices/net/eth@XX
> will cut it.

There is _no_ excuse for being terse.

Also, never EVER use special characters like "@" unless there is _reason_
to use them. I don't see any reason to make a filesystem look like perl.

Please use sane names like "disknnn" over insane cryptographically secure
filesystem contents like "sd@nnn".

		Linus

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:
> 
> On Thu, 20 Jun 2002, Martin Dalecki wrote:
> 
>>>	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
>>
>>                  ^^^^^^^^^^ You notice the redundancy in naming here :-).
> 
> 
> I'd rather have redundancy than have horrible names like just "0", thank
> you very much.
> 
> It takes up no space, all the dentries are virtual anyway, and a dentry
> embeds the storage for the first n characters (n ~16 or something like
> that).
> 
> 
>>Boah the chierachies are already deep enough. /devices/net/eth@XX
>>will cut it.
> 
> 
> There is _no_ excuse for being terse.

Yes indeed:

ls 	DIR
cp 	COPY
mv      REANME
cat     TYPE

Note: the VMS stuff was even longer. You ever used the "shell" there?

> Also, never EVER use special characters like "@" unless there is _reason_
> to use them. I don't see any reason to make a filesystem look like perl.

The reaons is that it is making the splitup betwen the enumeration
and naming part very easy. Not just for scripts but for C code as well.
Numbers get user quite frequently for versioning as well.
And I tought the above should be mainly used by programs?

> Please use sane names like "disknnn" over insane cryptographically secure
> filesystem contents like "sd@nnn".

I'm so used to sd@ :-). Don't invent where you can borrow - or you will
go the esperanto way.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> But:
> 
> 1. There was the mistake of using different major numbers
> for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).
> 
> 2. Then came devfs along and promised to slove this problem.
>     But people still complained about not beeing ablve to boot, after
>     I changed the registration name for IDE devices from "ide" to "ata".
>     This showed nicely that devfs doesn't cut it. It's useless for
>     the purpose of unification of access methods apparently.
> 
> 3. Now comes driverfs, which is basically a Solaris driver tree clone and
>     *repeats* the same errors as 1. and 2.:

driverfs is not a Solaris driver tree clone. Sure, it's similar, but I 
assure no inspiaration was derived from Solaris. The same is true for the 
Windows Driver Model (though bits of inspiration may have filtered into 
the initial driver tree from WDM via the ACPI people).

driverfs does not care about major and minor numbers (yet). 

driverfs does not attempt to replace the /dev hierarchy.

That said, driverfs will use major/minor numbers in the future, but it
will not care about what they are or who owns them. It will also offer a
solution to the device naming problem (like devfs), and provide a 
mechanism for maintaining /dev compatability. But, I'm foreshadowing. 

>   ./
> ./bus
> ./bus/usb
> ./bus/usb/drivers
> ./bus/usb/devices
> ./bus/usb/devices/002001
> ...
> ./bus/usb/devices/001000
> ./bus/pci
> ./bus/pci/drivers
> ./bus/pci/drivers/parport_pc
> ..
> ./bus/pci/drivers/usb-uhci-hcd
> ./bus/pci/drivers/e100
> ./bus/pci/devices
> ./bus/pci/devices/00:0c.1
> ...
> ./bus/pci/devices/00:00.0
> 
> 1. The /drivers information is useless. modutils are maintining they
> own information. For some jet unknow reason they manage to
> maintain te hierarchy entierly in user space.

You mean e.g. ./bus/pci/drivers/ ? I don't think it's useless at all. It 
provides a mechanism for drivers to export attributes specific to the 
drivers themselves (and not specific to a particular device). For example, 
if you want to turn on debugging on the fly in the e100 driver, it could 
export a 'debug' file, which the user could toggle. It would turn on 
debugging for the entire driver on the fly. 

It likely has a module parameter to do the same thing. But, that parameter 
is not available if you statically compile it into the kernel. And, module 
parameters are not tweakable on the fly. 

Rusty and I are talking at the kernel workshop on Monday about parameters.  
One of the topics is where module parameters leave off and driverfs starts
up. It would be really really nice to unify the representation of these
types of parameters. 

Plus, something that is easy to do is create symlinks in the drivers' 
directory to the devices in the physical hierarchy for the devices it's 
driving. 

> The bus suffix. is useless for any purpose I can imagine.
> Which kind of view is the above supposed to present?

It's the 'bus' view. Each bus should have a struct bus_type object that it 
registers on startup. (See the documentation I sent out a couple of weeks 
ago). It's then inserted into a flat list of bus types. 

Each bus keeps a list of devices and drivers. These lists are moved to the 
struct bus_type for centralized management. 

Everything is exported via driverfs because it's easy to do so, and 
because it can potentially be very useful. 

> ./root
> 
> 2. What is this root prefix good for?!

Every system has the concept of a 'root' device. It's a virtual device 
that doresn't physically exist. It's the start of the device tree. 

> ./root/pci0
>
> 3. Solaris is separating the name and enumeration part by @ for
> good reaons.

'pci0' is the bus ID of the first PCI bridge. Devices that exist on the 
board itself and not on a peripheral bus don't have a standard for bus 
IDs. So, I went with <canonical name><instance number>. I thought it was 
pretty clear what it meant...

> ./root/pci0/00:0c.1
> ./root/pci0/00:0c.1/resources
> 
> 4. resources? What is the semantics of this supposed to be?
> IO ranges, memmory mappings? Whatever. This is jet another
> ASCI view for data which is too specific and should be only
> maintained by the drivers itself internaly as it is.
> Since it's not used now it will open jet another room
> for arbitrary formating and random useless entires problems in the future.
> Much like the mess in /proc only repeated for every single device on the
> system.

I think just the opposite is true. The resources file is added by the PCI 
layer and exports the BARs of the device. Every PCI device has this data. 
The formatting of this file is handled by the PCI layer. Yes, it may be 
specific to PCI devices, but it is standard for each PCI device. 

If we ever move the resources array to struct device, we can move the 
creation and the formatting of the resources file to the core. Then, it's 
standard for every device. 

I don't want driverfs to end up like procfs with the random formatting
problem. I want driverfs files to be ASCII-only files with one value per
file. This cannot be programmatically enforced, so we must rely on social
engineering to enforce it. 

[ Also, the resources file also violates the second rule, since it's an 
array of information, but I don't know any better way to represent this. ]

driverfs files are named attribute pairs, where the name of the attribute 
is the name of the file, and the value is the contents. I've talked with 
people before about making them even easier to create, read, and write, in 
ways that enforce one value of a specific type to be exported. (I.e. 
making them very restrictive). Someday...

> ./root/pci0/00:0c.1/irq
> 
> 5. This is showing that the resources file above is useless, becouse
> I would rather love to consider irq as a resource.

Sure, but it's a separate field. 

> ./root/pci0/00:0c.1/power
> ./root/pci0/00:0c.1/name
> 
> 6. The /name is entierly redundant logically to the fact that we
> have already a unique path to the device. For "pretty" printing
> we have userspace. For PCI it's for example repeating the
> ID info found already by lspci.

Sure. But, we already have the information in struct device. Instead of 
using lspci, lsusb, lsfoo to ascertain the name, you can just cat the name 
file for any device on the system. (Though, I basically agree with the 
premise that that information doesn't need to be in the kernel in the 
first place)

> ./root/pci0/00:07.2/usb_bus
> 
> 7. What is the _bus? suffix good for? How does this releate
> to the /bus hierarchy?

It says that it's a USB hub. I believe the information is redundant, and 
there should be a patch to remove it. Greg? :)

> ./root/pci0/00:07.2/usb_bus/00
> 
> 9. Contrary to PCI we enumerate the busses apparently
> by one dir level and not a suffix on the usb prefix.

Yes, the directory names are bus-specific identifiers for the device. It's 
up to the bus enumerator to determine what they are, and really don't make 
any sense outside of the bus context. 

> ./root/pci0/00:07.1/ata@00
> ./root/pci0/00:07.1/ata@00/sd@0,0
> ./root/pci0/00:07.1/ata@00/sd@0,0/power
> ./root/pci0/00:07.1/ata@00/sd@0,0/name
> ./root/pci0/00:07.1/ata@00/power
> ./root/pci0/00:07.1/ata@00/name
> 
> Here I'm trying to fit the whole in some kind of
> physical view. I did sneak in the sd instead of
> hd in the futile hope that SCSI will pick up the same
> name. And I buy in to the idea of separating
> the enumeratin for the naming by a @.
> This way one has only to enumerate the
> dir only and no room for possible ambiguity is present.

ata@00 is the controller, right? And sd@0,0 is the first disk on the first
channel?? You don't need the former. It's already present as PCI device
00:07.1, and you shouldn't have a duplicate entry. 

sd@0,0 can simply be 0,0 (though I don't personally like commas). You 
don't really _need_ any more context in there, since it's implied by your 
location in the tree.

> But it was entierly behind me how to fit this
> in to the sheme other sd@4,0:h,raw
> OS-es are using. And finally how would one fit this in to the
> partitioning shemes? For the system aprtitions are simply
> block devices hanging off the corresponding block device.

Partitions are purely logical entities on a physical disk. They have no 
presence in the physical device tree. 

> However we can see that the driver filesystem is
> inconsistant on the kind of enumeration it should
> provide. See the colon in sd@0,0 and the whole subdir
> crazyness... So do we distingish different devices by a subdir?
> Or do we do it by an unique enumeration suffix?

I don't understand your question. Yes enumeration is inconsistent, because 
it's dependent on the bus-supplied ID. 

> And last but not least: I still don't see any kind
> of abstraction there which would allow to easly enumerate
> for example all disks in the system.

It doesn't exist yet. Disks are a device class. When a disk driver 
discovers a disk, it will register it with the disk class. The class 
will then enumerate the disk. 

> However a simple major number range for disks 1 to 16000 would
> be ideal. And I bet that at some (not too distant) day we will
> simple have to reassign those numbers and be done.

Sure. Once device class supports materializes, classes will register and
can be assigned a dynamic major number even (if they don't already have
one). As devices (and partitions) are discovered, we can assign minor
numbers (dynamically!), and call /sbin/hotplug to notify userspace of the
discovery. It can use that information to create device nodes based on 
user-defined policy. 

[ Yes, that is similar to what devfs does, but there are several distinct 
differences... ]

I imagine we'll have a lot to discuss in Ottawa...

	-pat

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Patrick Mochel napisał:
>>But:
>>
>>1. There was the mistake of using different major numbers
>>for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).
>>
>>2. Then came devfs along and promised to slove this problem.
>>    But people still complained about not beeing ablve to boot, after
>>    I changed the registration name for IDE devices from "ide" to "ata".
>>    This showed nicely that devfs doesn't cut it. It's useless for
>>    the purpose of unification of access methods apparently.
>>
>>3. Now comes driverfs, which is basically a Solaris driver tree clone and
>>    *repeats* the same errors as 1. and 2.:
> 
> 
> driverfs is not a Solaris driver tree clone. Sure, it's similar, but I 
> assure no inspiaration was derived from Solaris. The same is true for the 
> Windows Driver Model (though bits of inspiration may have filtered into 
> the initial driver tree from WDM via the ACPI people).

Yes that's the pitty :-).

> driverfs does not care about major and minor numbers (yet). 
> 
> driverfs does not attempt to replace the /dev hierarchy.
> 
> That said, driverfs will use major/minor numbers in the future, but it
> will not care about what they are or who owns them. It will also offer a
> solution to the device naming problem (like devfs), and provide a 
> mechanism for maintaining /dev compatability. But, I'm foreshadowing. 

Irony by someone remembering the days devfs wasn't in the main
kernel tree and who was against it:
I tought devfs already solves those problems...


> You mean e.g. ./bus/pci/drivers/ ? I don't think it's useless at all. It 
> provides a mechanism for drivers to export attributes specific to the 
> drivers themselves (and not specific to a particular device). For example, 
> if you want to turn on debugging on the fly in the e100 driver, it could 
> export a 'debug' file, which the user could toggle. It would turn on 
> debugging for the entire driver on the fly. 

Interface on the heap phenomena. If someone writing a driver wished to have
this he could have registered some sysctl already. Becouse
this is precisely the interface fitting the purpose you describe.

> It likely has a module parameter to do the same thing. But, that parameter 
> is not available if you statically compile it into the kernel. And, module 
> parameters are not tweakable on the fly. 

See above - sysctl.

> Rusty and I are talking at the kernel workshop on Monday about parameters.  
> One of the topics is where module parameters leave off and driverfs starts
> up. It would be really really nice to unify the representation of these
> types of parameters. 

Indeed yes but it doesn't have to be done under the umbrella of
driverfs.

> Plus, something that is easy to do is create symlinks in the drivers' 
> directory to the devices in the physical hierarchy for the devices it's 
> driving. 

??


>>The bus suffix. is useless for any purpose I can imagine.
>>Which kind of view is the above supposed to present?
> 
> 
> It's the 'bus' view. Each bus should have a struct bus_type object that it 
> registers on startup. (See the documentation I sent out a couple of weeks 
> ago). It's then inserted into a flat list of bus types. 
> 
> Each bus keeps a list of devices and drivers. These lists are moved to the 
> struct bus_type for centralized management. 
> 
> Everything is exported via driverfs because it's easy to do so, and 
> because it can potentially be very useful. 
> 
> 
>>./root
>>
>>2. What is this root prefix good for?!
> 
> 
> Every system has the concept of a 'root' device. It's a virtual device 
> that doresn't physically exist. It's the start of the device tree. 

That's called /. BTW. If anything I'm missing there is the
representation of the very first BUS out there: CPU!!!

>>./root/pci0
>>
>>3. Solaris is separating the name and enumeration part by @ for
>>good reaons.
> 
> 
> 'pci0' is the bus ID of the first PCI bridge. Devices that exist on the 
> board itself and not on a peripheral bus don't have a standard for bus 
> IDs. So, I went with <canonical name><instance number>. I thought it was 
> pretty clear what it meant...

Yes and the *@* should be there to separate naming from enumeration part.
However I see in the above hierarchy no clear mandate for
where enumeration does happen - dir name subdirs named 0, 1, 2, 3,

>>./root/pci0/00:0c.1
>>./root/pci0/00:0c.1/resources

> I don't want driverfs to end up like procfs with the random formatting
> problem. I want driverfs files to be ASCII-only files with one value per
> file. This cannot be programmatically enforced, so we must rely on social
> engineering to enforce it. 

Forget it. I have warned against those problems even before /proc
became mandatory. You see now where we are. You are just moving
the arbitrary part away from the content to the fs name level.

> [ Also, the resources file also violates the second rule, since it's an 
> array of information, but I don't know any better way to represent this. ]

You see: ascii files are *evil* not just due to buffer overrun attacks.

> driverfs files are named attribute pairs, where the name of the attribute 
> is the name of the file, and the value is the contents. I've talked with 
> people before about making them even easier to create, read, and write, in 
> ways that enforce one value of a specific type to be exported. (I.e. 
> making them very restrictive). Someday...
> 
> 
>>./root/pci0/00:0c.1/irq
>>
>>5. This is showing that the resources file above is useless, becouse
>>I would rather love to consider irq as a resource.
> 
> 
> Sure, but it's a separate field. 
> 
> 
>>./root/pci0/00:0c.1/power
>>./root/pci0/00:0c.1/name
>>
>>6. The /name is entierly redundant logically to the fact that we
>>have already a unique path to the device. For "pretty" printing
>>we have userspace. For PCI it's for example repeating the
>>ID info found already by lspci.
> 
> 
> Sure. But, we already have the information in struct device. Instead of 
> using lspci, lsusb, lsfoo to ascertain the name, you can just cat the name 
> file for any device on the system. (Though, I basically agree with the 
> premise that that information doesn't need to be in the kernel in the 
> first place)

Argument frequently enough repeated by the advertisers of
the /proc mess... The kernel should be what it's name says -
just the kernel of the things and not the all for everything.

>>./root/pci0/00:07.2/usb_bus
>>
>>7. What is the _bus? suffix good for? How does this releate
>>to the /bus hierarchy?
> 
> 
> It says that it's a USB hub. I believe the information is redundant, and 
> there should be a patch to remove it. Greg? :)
> 
> 
>>./root/pci0/00:07.2/usb_bus/00
>>
>>9. Contrary to PCI we enumerate the busses apparently
>>by one dir level and not a suffix on the usb prefix.

You see I understood that pci0 is for the first bridge.
And you see that in comparision to /proc you are moving
the "arbitrary" part just from the file level to the directory
level.

Once reason I advertize for short names is the fact
that they will prevent people psychologicall from inventing
names like:

/devices/pci0/..../my_beloved_toy_device_which_....


> Yes, the directory names are bus-specific identifiers for the device. It's 
> up to the bus enumerator to determine what they are, and really don't make 
> any sense outside of the bus context. 
> 
> 
>>./root/pci0/00:07.1/ata@00
>>./root/pci0/00:07.1/ata@00/sd@0,0
>>./root/pci0/00:07.1/ata@00/sd@0,0/power
>>./root/pci0/00:07.1/ata@00/sd@0,0/name
>>./root/pci0/00:07.1/ata@00/power
>>./root/pci0/00:07.1/ata@00/name
>>
>>Here I'm trying to fit the whole in some kind of
>>physical view. I did sneak in the sd instead of
>>hd in the futile hope that SCSI will pick up the same
>>name. And I buy in to the idea of separating
>>the enumeratin for the naming by a @.
>>This way one has only to enumerate the
>>dir only and no room for possible ambiguity is present.
> 
> 
> ata@00 is the controller, right? And sd@0,0 is the first disk on the first
> channel?? You don't need the former. It's already present as PCI device
> 00:07.1, and you shouldn't have a duplicate entry. 
> 
> sd@0,0 can simply be 0,0 (though I don't personally like commas). You 
> don't really _need_ any more context in there, since it's implied by your 
> location in the tree.

I would love to distingish between device types sd - disk
sr - -CD-ROM DVD or whatever.
Please note that you have only one single PCI device but from
the physical perspecitve two buses hanging down from it called
channels (The ribbon between the disk and controller).
So a ATA host chip controller is basically even in reality
a PCI to ISA bus bridge. For example it's quite common
in notebooks to use the second ATA channel precisely as a bridge
between the host PCI and ISA on the expander....
Just forget that there is usually only a master and slave
on this bus please.

> Partitions are purely logical entities on a physical disk. They have no 
> presence in the physical device tree. 

Device drivers are purely logical entities of the kernel. They have
no presence in the physical device tree.

But they have a presence in /dev/ and are the entity we act on.

>>However we can see that the driver filesystem is
>>inconsistant on the kind of enumeration it should
>>provide. See the colon in sd@0,0 and the whole subdir
>>crazyness... So do we distingish different devices by a subdir?
>>Or do we do it by an unique enumeration suffix?

> I imagine we'll have a lot to discuss in Ottawa...

Yeep. I'm looking forward to it. Let's count the ARM CPUs attached
to my notebook after some real beer :-).

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] /proc/scsi/map

[Pavel Machek]

Hi!

> That's called /. BTW. If anything I'm missing there is the
> representation of the very first BUS out there: CPU!!!

And if you have four cpus, two of them having southbridge with PCI?
You might make cpu%d the root....
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> The driverfs patch for SCSI that was recently posted was the kernel portion of 
> a device naming project that is intended to support all devices, at least the 
> ones that implement to driverfs in a standard way. There are three items that
> IMHO should be considered as part of the standard set that driverfs requires:
> 
> 1. device type - It appears that Pat is heading down this path with the class
> 	type support so maybe this is a no brainer. Currently the scsi
> 	driverfs provides a "type" file to contain this info. The current
> 	strings used are taken from the scsi_device_types[] but should be
> 	replaced with the system wide device types that driverfs will provide.

Yes, they are pretty much the same thing. 

> 2. uid - Since topology and discovery order of hardware can change, the
> 	driverfs path names to a device are also subject to change. To
> 	easily identify a device I think it's important that the driverfs
> 	bus implementations be responsible for create a unique identifier.
> 
> 	Since each bus and the devices attached to it will have varying
> 	capabilities for identifying themselves the contents for this file
> 	should probably be a variable length string.
> 
> 	Even for older devices that can't do a great job of providing info to
> 	uniquely identify themselves, the driverfs tree provides the nice
> 	topological context to fall back upon that allows at least as
> 	good of a job to be done as we do today.
> 
> 	The scsi patch currently creates uid info from the INQUIRY evpd pages
> 	and makes it available in the name file. I would prefer to see a
> 	new standard uid file and let the name file contain a descriptive 
> 	(non-unique) name.

Yes, I agree. UUIDs are needed to do any type of persistant naming (well). 
As you say, there are varying ways for determining the UUID, and some ways 
may not be present for some devices. It will be up to the various driver 
levels to determine if they can determine a better UUID than higher level 
layers.

For example, PCI by default doesn't have very good unique information. 
About the best it can do is something like munging together:

	<bus><device><function><class><subclass>

If that device is a network card, the class driver can set the UUID of the 
device to the MAC of the device. (Network cards won't be named, but it's 
only an example). (Or, the label of a disk). 

Further, if the device driver knows an even better way to ID the device, 
e.g. via a serial number on the device, it can do so. 

Some buses and their driver won't have to worry, since that information is 
mandatory in the devices. 

> 3. kdev - To create/manage/interface with the device node we need to know the
>  	kdev.

Sure. I don't have objections to this. It will likely become obvious that 
we need this later on...

> Because of coldplugging this information should be available in each
> driverfs device directory. Also, adding the driverfs path name on
> /sbin/hotplug events and allowing the consumer to retrieve the info
> from the filesystem might help simplify some of these implementations
> too.

This information should be exported, I agree. But, we could theoretically 
achieve a state where every device discovered gets a call to 
/sbin/hotplug. 

[ With initramfs, we could have the rootfs partition mounted before we 
start probing for any devices. As long as that had /sbin/hotplug, and the 
means and policy to name devices, it should work. ]

	-pat

[PATCH] driverfs scsi for 2.5.24

[Douglas Gilbert]

[-- Attachment #1: Type: text/plain, Size: 10160 bytes --]

Attached is Mike Sullivan's driverfs patch which was released
on June 21. It has been minimally changed so it applies to
lk 2.5.24 . 

Here are Mike's original notes:

Mike Sullivan wrote:
> 
> The driverfs patch for SCSI that was recently posted was the kernel portion of
> a device naming project that is intended to support all devices, at least the
> ones that implement to driverfs in a standard way. There are three items that
> IMHO should be considered as part of the standard set that driverfs requires:
> 
> 1. device type - It appears that Pat is heading down this path with the class
>         type support so maybe this is a no brainer. Currently the scsi
>         driverfs provides a "type" file to contain this info. The current
>         strings used are taken from the scsi_device_types[] but should be
>         replaced with the system wide device types that driverfs will provide.
> 
> 2. uid - Since topology and discovery order of hardware can change, the
>         driverfs path names to a device are also subject to change. To
>         easily identify a device I think it's important that the driverfs
>         bus implementations be responsible for create a unique identifier.
> 
>         Since each bus and the devices attached to it will have varying
>         capabilities for identifying themselves the contents for this file
>         should probably be a variable length string.
> 
>         Even for older devices that can't do a great job of providing info to
>         uniquely identify themselves, the driverfs tree provides the nice
>         topological context to fall back upon that allows at least as
>         good of a job to be done as we do today.
> 
>         The scsi patch currently creates uid info from the INQUIRY evpd pages
>         and makes it available in the name file. I would prefer to see a
>         new standard uid file and let the name file contain a descriptive
>         (non-unique) name.
> 
> 3. kdev - To create/manage/interface with the device node we need to know the
>         kdev.
> 
> Because of coldplugging this information should be available in each driverfs
> device directory. Also, adding the driverfs path name on /sbin/hotplug
> events and allowing the consumer to retrieve the info from the filesystem might
> help simplify some of these implementations too.
> 
> The devnaming utility that is based on this strategy is available at
> http://www-124.ibm.com/devreg/
> 
> I'd welcome any thoughts or suggestions.

It will probably take a few iterations before we get
close to an "approved" naming model :-)
 
So people have some idea what this patch generates, here
is my system's "/proc/scsi/scsi" followed by a "du -a"
at the top of the driverfs tree:

$ cat /proc/scsi/scsi
Attached devices: 
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: FUJITSU  Model: MAM3184MP        Rev: 0105
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 09 Lun: 00
  Vendor: SEAGATE  Model: ST318451LW       Rev: 0003
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: Linux    Model: scsi_debug       Rev: 0003
  Type:   Direct-Access                    ANSI SCSI revision: 03

$ du -a
...
0       ./bus/usb
0       ./bus/scsi/drivers/sr
0       ./bus/scsi/drivers/sg
0       ./bus/scsi/drivers/sd		# empty directory
0       ./bus/scsi/drivers
0       ./bus/scsi/devices/3:0:0:0:disc  # symlinks across to "root" subtree
0       ./bus/scsi/devices/3:0:0:0:gen
0       ./bus/scsi/devices/3:0:0:0
0       ./bus/scsi/devices/1:0:9:0:gen
0       ./bus/scsi/devices/1:0:0:0:gen
0       ./bus/scsi/devices/1:0:9:0:p7
0       ./bus/scsi/devices/1:0:9:0:p6
0       ./bus/scsi/devices/1:0:9:0:p5
0       ./bus/scsi/devices/1:0:9:0:p4
0       ./bus/scsi/devices/1:0:9:0:p3
0       ./bus/scsi/devices/1:0:9:0:p2
0       ./bus/scsi/devices/1:0:9:0:p1
0       ./bus/scsi/devices/1:0:9:0:disc
0       ./bus/scsi/devices/1:0:0:0:p7
0       ./bus/scsi/devices/1:0:0:0:p6
0       ./bus/scsi/devices/1:0:0:0:p5
0       ./bus/scsi/devices/1:0:0:0:p4
0       ./bus/scsi/devices/1:0:0:0:p3
0       ./bus/scsi/devices/1:0:0:0:p2
0       ./bus/scsi/devices/1:0:0:0:p1
0       ./bus/scsi/devices/1:0:0:0:disc
0       ./bus/scsi/devices/1:0:9:0
0       ./bus/scsi/devices/1:0:0:0
0       ./bus/scsi/devices
0       ./bus/scsi
....
0       ./bus/pci/devices/00:0c.1 # symlinks, Tekram dual controller
0       ./bus/pci/devices/00:0c.0
....
0       ./bus/pci
0       ./bus

# scsi_debug "virtual" host bubbles to the top of "root"
# hierarchy because it has no "parent" bus type (i.e. it
# isn't pci). Why is the <h,c,t,l> given twice?
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/kdev
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/type
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/power
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/name  # S1234Linuxdisc
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/kdev
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/type
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/power
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/name   # S1234Linuxgeneric
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen
0       ./root/scsi3/3:0:0:0/type
0       ./root/scsi3/3:0:0:0/power
0       ./root/scsi3/3:0:0:0/name  # S1234Linux
0       ./root/scsi3/3:0:0:0
0       ./root/scsi3/power
0       ./root/scsi3/name          # scsi_debug, Version: 1.59 ....
0       ./root/scsi3
0       ./root/pci0/00:0d.0/resources
0       ./root/pci0/00:0d.0/irq
.... 
0       ./root/pci0/00:0c.1/scsi2/power
0       ./root/pci0/00:0c.1/scsi2/name   # sym-2.1.16a
0       ./root/pci0/00:0c.1/scsi2
0       ./root/pci0/00:0c.1/resources
0       ./root/pci0/00:0c.1/irq
0       ./root/pci0/00:0c.1/power
0       ./root/pci0/00:0c.1/name      # PCI device 1000:0020
0       ./root/pci0/00:0c.1
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/name
              # S3CC01TTG000071033QEASEAGATEgeneric
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/name
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7
...
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/name
              # S3CC01TTG000071033QEASEAGATEpart1
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/name
              # S3CC01TTG000071033QEASEAGATEdisc 
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/name
              # S3CC01TTG000071033QEASEAGATE
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/name
              # SUKS0P1B009PFFUJITSUgeneric
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/name
              # SUKS0P1B009PFFUJITSUpart7
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p6/kdev
....
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/name
              # SUKS0P1B009PFFUJITSUpart1
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/name
              # SUKS0P1B009PFFUJITSUdisc
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/name
              # SUKS0P1B009PFFUJITSU
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0
0       ./root/pci0/00:0c.0/scsi1/power
0       ./root/pci0/00:0c.0/scsi1/name
              # sym-2.1.16a
0       ./root/pci0/00:0c.0/scsi1
0       ./root/pci0/00:0c.0/resources
0       ./root/pci0/00:0c.0/irq
0       ./root/pci0/00:0c.0/power
0       ./root/pci0/00:0c.0/name
0       ./root/pci0/00:0c.0
....
0       ./root/pci0/00:04.1/ata@01/power
0       ./root/pci0/00:04.1/ata@01/name  # ATA/ATAPI Host-Channel
0       ./root/pci0/00:04.1/ata@01


It would be useful if Martin could show us one of his ATA
driverfs trees.

Patrick mentioned that we can soon expect these directories:
     /driverfs/class/disk
     /driverfs/class/tape
     /driverfs/class/cd  (or cd-dvd, or ...)
and perhaps
     /driverfs/class/misc
for those nasty devices (e.g. tape robots and storage enclosures)
that need pass through drivers like sg. 
The "/driverfs/class/disk"
directory would contain all attached disks (i.e.
ATA, SCSI, USB ...) with enumerated names (i.e.
"disk0", "disk1"). These enumerated names would be symlinks
to the device.


I'll start with one suggestion: perhaps "kdev" could
be replaced by two files: "major" and "minor".

Comments?

Doug Gilbert

[-- Attachment #2: scsi-driverfs_2524.diff.gz --]
[-- Type: application/x-gzip, Size: 8809 bytes --]

Re: [PATCH] driverfs scsi for 2.5.24

[James Bottomley]

Actually, the patch already went into Linus' BK tree and will be in 2.5.25.

dougg@torque.net said:
> It will probably take a few iterations before we get close to an
> "approved" naming model :-) 

That's part of the reason for putting it in early...

> I'll start with one suggestion: perhaps "kdev" could be replaced by
> two files: "major" and "minor". 

I think kdev belongs in the (not yet implemented) class driver, doesn't it? 
(Pat?), so we shouldn't be doing anything to expose it in SCSI.  If it's done 
at the class level, the kdev policy will be set globally.

I think the partition `name' file should reflect the partition UUID if one 
exists, and that the disc `name' file should be mutable by root so we can do 
fixups (from hotplug) for the exceptional devices that don't have a proper 
unique name.

As far as numeric enumerations go, I think we can begin to move away from 
them.  Everything that has a parent bus no longer needs a host number since it 
has a unique position in the device tree.  The mid-layer itself thinks of host 
enumerations in terms of a linked list, so it doesn't need the number either.  
This way, we should be able to finesse all our complex host addition/removal 
numbering issues that plague 2.4.

I also think that target numbers only make sense when they exist in reality 
(like on a parallel bus).  quite a few fibre channel drivers do internal 
remapping to real target identifiers; I see no reason why they can't just 
expose the ASCII representation of what they use for the device on the bus to 
driverfs now.

LUNs are probably still usefully numeric, but it would be nice to use the 
filesystem hierarchy to represent the SCSI-3 LUN hierarchy.

The key to using driverfs efficiently is to remember that it simply exposes to 
the user how the SCSI subsystem sees the device tree.  Therefore, once we have 
the simplest useful device tree inside SCSI, that will be the way the user 
sees it as well.

James

Re: [PATCH] driverfs scsi for 2.5.24

[Douglas Gilbert]

James Bottomley wrote:
> 
> Actually, the patch already went into Linus' BK tree and will be in 2.5.25.
> 
> dougg@torque.net said:
> > It will probably take a few iterations before we get close to an
> > "approved" naming model :-)
> 
> That's part of the reason for putting it in early...
> 
> > I'll start with one suggestion: perhaps "kdev" could be replaced by
> > two files: "major" and "minor".
> 
> I think kdev belongs in the (not yet implemented) class driver, doesn't it?
> (Pat?), so we shouldn't be doing anything to expose it in SCSI.  If it's done
> at the class level, the kdev policy will be set globally.
> 
> I think the partition `name' file should reflect the partition UUID if one
> exists, and that the disc `name' file should be mutable by root so we can do
> fixups (from hotplug) for the exceptional devices that don't have a proper
> unique name.

So will partitions only be visible in the "class" subtree?
I still want to see an example of what disks (and their
partitions) will look like in the "class" subtree.

Patrick Mochel's 3rd July class.txt file gave a networking example:
	/devices/class/net/eth
	/devices/class/net/eth/eth1
	/devices/class/net/eth/eth1/physical  # symlink
	/devices/class/net/eth/eth0
	/devices/class/net/eth/eth0/physical
So "net" is the class and "eth" is the subclass under which
there is an enumeration. Given a "disk" class does it have
any subclasses? [Answering "scsi" and "ata" would probably not 
be politically correct.]
 
> As far as numeric enumerations go, I think we can begin to move away from
> them.  Everything that has a parent bus no longer needs a host number since it
> has a unique position in the device tree.  The mid-layer itself thinks of host
> enumerations in terms of a linked list, so it doesn't need the number either.
> This way, we should be able to finesse all our complex host addition/removal
> numbering issues that plague 2.4.

Enumerations seem to be moving to a different level.
 
> I also think that target numbers only make sense when they exist in reality
> (like on a parallel bus).  quite a few fibre channel drivers do internal
> remapping to real target identifiers; I see no reason why they can't just
> expose the ASCII representation of what they use for the device on the bus to
> driverfs now.

According to SAM-2, Annex A, Table A.3 an FCP-2 target
identifier is 3 bytes of binary. The problems arise with
SRP (infiniband), iSCSI and SBP-3 (iee1394). That table
suggests that 262 bytes of UTF-8 (ascii) is the worst case
for an iSCSI initiator port identifier.
In SAM-2 parlance this would suggest an array like:
	uint8_t port_id[262];

> LUNs are probably still usefully numeric, but it would be nice to use the
> filesystem hierarchy to represent the SCSI-3 LUN hierarchy.

Patrick Mansfield seemed uncomfortable about foregoing
the existing numeric luns. So perhaps we could keep the
existing:
	uint32_t lun;
and add
	uint8_t lu_id[8];

That way we keep what REPORT LUNS tells us, and for the
vast majority of cases are able to generate a numeric
lun from it.

> The key to using driverfs efficiently is to remember that it simply exposes to
> the user how the SCSI subsystem sees the device tree.  Therefore, once we have
> the simplest useful device tree inside SCSI, that will be the way the user
> sees it as well.

When I tried to place some of the scsi_debug lower level driver
parameters into driverfs I found nowhere to put them. It seems
that the Scsi_Host_Template structure should have a
"struct device_driver scsi_driverfs_lldriver" entry in it.
The Scsi_Device_Template structure has a "struct device_driver"
entry, why not Scsi_Host_Template?

>From an OO perspective, "struct device" is a base class from
which Scsi_Device and Scsi_Host are derived while
"struct device_driver" is a base class from which
Scsi_Device_Template and Scsi_Host_Template are derived.
Patrick Mochel's documents seem to be explaning a virtual
destructor mechanism as well.

Doug Gilbert

Re: [PATCH] driverfs scsi for 2.5.24

[Patrick Mochel]

> So will partitions only be visible in the "class" subtree?
> I still want to see an example of what disks (and their
> partitions) will look like in the "class" subtree.

Do you need partitions visible from driverfs at all? They are simply
logical entities on the physical device. What do they get in driverfs,
direcetories? (Sorry, I still haven't looked at the patch; I don't
actually have any SCSI devices any more. But, I will look at it soon. I 
promise.) 

> Patrick Mochel's 3rd July class.txt file gave a networking example:
> 	/devices/class/net/eth
> 	/devices/class/net/eth/eth1
> 	/devices/class/net/eth/eth1/physical  # symlink
> 	/devices/class/net/eth/eth0
> 	/devices/class/net/eth/eth0/physical
> So "net" is the class and "eth" is the subclass under which
> there is an enumeration. Given a "disk" class does it have
> any subclasses? [Answering "scsi" and "ata" would probably not 
> be politically correct.]

I wouldn't think that you would need subclasses for disks. You may have 
multiple interfaces for each disk (there's a few recent messages on lkml 
about this), but that's another story. 

> > LUNs are probably still usefully numeric, but it would be nice to use the
> > filesystem hierarchy to represent the SCSI-3 LUN hierarchy.
> 
> Patrick Mansfield seemed uncomfortable about foregoing
> the existing numeric luns. So perhaps we could keep the
> existing:
> 	uint32_t lun;
> and add
> 	uint8_t lu_id[8];

Out of curiosity, why do you guys use types and not u32, u8, etc? 

> > The key to using driverfs efficiently is to remember that it simply exposes to
> > the user how the SCSI subsystem sees the device tree.  Therefore, once we have
> > the simplest useful device tree inside SCSI, that will be the way the user
> > sees it as well.
...
> >From an OO perspective, "struct device" is a base class from
> which Scsi_Device and Scsi_Host are derived while
> "struct device_driver" is a base class from which
> Scsi_Device_Template and Scsi_Host_Template are derived.
> Patrick Mochel's documents seem to be explaning a virtual
> destructor mechanism as well.

Yes. Both statements are right on. You SCSI guys are so good.

	-pat

Re: [PATCH] driverfs scsi for 2.5.24

[Patrick Mochel]

On Wed, 3 Jul 2002, James Bottomley wrote:

> Actually, the patch already went into Linus' BK tree and will be in 2.5.25.
> 
> dougg@torque.net said:
> > It will probably take a few iterations before we get close to an
> > "approved" naming model :-) 
> 
> That's part of the reason for putting it in early...
> 
> > I'll start with one suggestion: perhaps "kdev" could be replaced by
> > two files: "major" and "minor". 
> 
> I think kdev belongs in the (not yet implemented) class driver, doesn't it? 
> (Pat?), so we shouldn't be doing anything to expose it in SCSI.  If it's done 
> at the class level, the kdev policy will be set globally.

Yes. However, if you guys can use it now, go ahead and implement it where
you see fit. Once the infrasructure is in place, we can push it upwards to
the generic structure. 

> I think the partition `name' file should reflect the partition UUID if one 
> exists, and that the disc `name' file should be mutable by root so we can do 
> fixups (from hotplug) for the exceptional devices that don't have a proper 
> unique name.

Dave Brownell (USB guy) brought this up a few days ago. The 'name' field 
is intended to be a user-friendly ascii description of the device. I'm 
considering changing the name to 'descr' to end all confusion. 

I intend to create a field to represent the unique identifier (maybe 
'uuid'). Again, if you guys need something like that, go ahead and put it 
in the SCSI-specific structure, and let it pushed upwards when the time 
comes. 

	-pat

Re: [PATCH] /proc/scsi/map

[Oliver Xymoron]

On Thu, 20 Jun 2002, Patrick Mochel wrote:

> > But it was entierly behind me how to fit this
> > in to the sheme other sd@4,0:h,raw
> > OS-es are using. And finally how would one fit this in to the
> > partitioning shemes? For the system aprtitions are simply
> > block devices hanging off the corresponding block device.
>
> Partitions are purely logical entities on a physical disk. They have no
> presence in the physical device tree.

As I raised elsewhere in this thread, the distinction between physical and
logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
to SCSI-over-Fibre Channel, except that rather than using an embedded FC
stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
disk/tape/whatever as a local device. Ergo, it ought to show up in the
device tree so that it can be discovered in the same way. But where?

This is only one step (the SCSI midlayer) removed from the logical devices
created by partitioning, LVM, NBD, MD, loopback, ramdisk and the like,
that again, ought to be discoverable in the same way as all other block
devices. Perhaps we need root/{virtual,logical}?

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] /proc/scsi/map

[Nick Bellinger]

On Fri, 2002-06-21 at 15:33, Oliver Xymoron wrote:
> On Thu, 20 Jun 2002, Patrick Mochel wrote:
> 
> > > But it was entierly behind me how to fit this
> > > in to the sheme other sd@4,0:h,raw
> > > OS-es are using. And finally how would one fit this in to the
> > > partitioning shemes? For the system aprtitions are simply
> > > block devices hanging off the corresponding block device.
> >
> > Partitions are purely logical entities on a physical disk. They have no
> > presence in the physical device tree.
> 
> As I raised elsewhere in this thread, the distinction between physical and
> logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> disk/tape/whatever as a local device. Ergo, it ought to show up in the
> device tree so that it can be discovered in the same way. But where?
> 
> This is only one step (the SCSI midlayer) removed from the logical devices
> created by partitioning, LVM, NBD, MD, loopback, ramdisk and the like,
> that again, ought to be discoverable in the same way as all other block
> devices. Perhaps we need root/{virtual,logical}?
> 

The interaction between iSCSI & driverfs does pose an interesting
problem:

On one hand I tend to lead toward the view of a physical device. 
The reason being that there will never be a distinction as far as the
kernel is concerned (other than driverfs of course) that a SCSI upper
level driver (hopefully soon to be a personality driver) using a iSCSI
Initiator low-level driver is not really a physical host. 

On the other hand there is the obvious fact that an iSCSI initiator
driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
etc, is out of the question.  There is a real need for a solution to
handle virtual devices (as stated your previous message) that are not
assoicated with any physical connectors.  

Not being too fimilar with driverfs,  what are the options with regard
to virtual devices as things currently stand without tainting the
elegant tree that is provides?
				
				Nicholas Bellinger

Re: [PATCH] /proc/scsi/map

[Douglas Gilbert]

Nick Bellinger wrote:
> 
> On Fri, 2002-06-21 at 15:33, Oliver Xymoron wrote:
> > On Thu, 20 Jun 2002, Patrick Mochel wrote:
> >
> > > > But it was entierly behind me how to fit this
> > > > in to the sheme other sd@4,0:h,raw
> > > > OS-es are using. And finally how would one fit this in to the
> > > > partitioning shemes? For the system aprtitions are simply
> > > > block devices hanging off the corresponding block device.
> > >
> > > Partitions are purely logical entities on a physical disk. They have no
> > > presence in the physical device tree.
> >
> > As I raised elsewhere in this thread, the distinction between physical and
> > logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> > to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> > stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> > disk/tape/whatever as a local device. Ergo, it ought to show up in the
> > device tree so that it can be discovered in the same way. But where?
> >
> > This is only one step (the SCSI midlayer) removed from the logical devices
> > created by partitioning, LVM, NBD, MD, loopback, ramdisk and the like,
> > that again, ought to be discoverable in the same way as all other block
> > devices. Perhaps we need root/{virtual,logical}?
> >
> 
> The interaction between iSCSI & driverfs does pose an interesting
> problem:
> 
> On one hand I tend to lead toward the view of a physical device.
> The reason being that there will never be a distinction as far as the
> kernel is concerned (other than driverfs of course) that a SCSI upper
> level driver (hopefully soon to be a personality driver) using a iSCSI
> Initiator low-level driver is not really a physical host.
> 
> On the other hand there is the obvious fact that an iSCSI initiator
> driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
> etc, is out of the question.  There is a real need for a solution to
> handle virtual devices (as stated your previous message) that are not
> assoicated with any physical connectors.
> 
> Not being too fimilar with driverfs,  what are the options with regard
> to virtual devices as things currently stand without tainting the
> elegant tree that is provides?

iSCSI introduces some other issues. The SCSI subsystem has
a 4 byte target (port) identifier at the moment. However Annex A
of the SAM-2 draft ( http://www.t10.org ) indicates that it should
be 258 bytes for iSCSI (and 11 bytes for ieee1394). For iSCSI the
target port identifier is a WWUI plus a 2 byte target portal group 
tag. A WWUI looks like:
  com.disk-vendor.diskarrays.sn.45678

Also the SCSI subsystem has tended to hide the the initiator's
own identifier (this is usually id 7 on the SCSI parallel bus).
For iSCSI it may be worthwhile to make the initiator port 
identifier visible in driverfs.

There is also the case where you want a box to appear to
the network as an iSCSI target. In this case once a iSCSI
login is complete you might want to represent the initiator
in the driverfs tree. For iSCSI, the initiator port identifier 
is a WWUI plus a 6 byte "inititator session id" for a total
of 262 bytes.

So the "target id" we put in driverfs could have one of
these suggested formats:
   <number>              - 0 to 1 for ATA
   <number>              - 0 to 15 for SCSI parallel interface
   <number>              - 24 bit number for fibre channel
   <EUI 64+discovery_id> - ieee1394
   <???>                 - usb (mass storage + scanner)
   <WWUI> ":" <num>      - iSCSI   [something better than ":"?]


We should also be moving towards 8 byte luns which in one
descriptor format are a 4 level hierarchy (2 bytes at each
level).

Doug Gilbert

Re: [PATCH] /proc/scsi/map

[Nick Bellinger]

On Sat, 2002-06-22 at 13:41, Douglas Gilbert wrote:
> > 
> > The interaction between iSCSI & driverfs does pose an interesting
> > problem:
> > 
> > On one hand I tend to lead toward the view of a physical device.
> > The reason being that there will never be a distinction as far as the
> > kernel is concerned (other than driverfs of course) that a SCSI upper
> > level driver (hopefully soon to be a personality driver) using a iSCSI
> > Initiator low-level driver is not really a physical host.
> > 
> > On the other hand there is the obvious fact that an iSCSI initiator
> > driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
> > etc, is out of the question.  There is a real need for a solution to
> > handle virtual devices (as stated your previous message) that are not
> > assoicated with any physical connectors.
> > 
> > Not being too fimilar with driverfs,  what are the options with regard
> > to virtual devices as things currently stand without tainting the
> > elegant tree that is provides?
> 
> iSCSI introduces some other issues. The SCSI subsystem has
> a 4 byte target (port) identifier at the moment. However Annex A
> of the SAM-2 draft ( http://www.t10.org ) indicates that it should
> be 258 bytes for iSCSI (and 11 bytes for ieee1394). For iSCSI the
> target port identifier is a WWUI plus a 2 byte target portal group 
> tag. A WWUI looks like:
>   com.disk-vendor.diskarrays.sn.45678

Yikes, 4 bytes?  Is there any special considerations bumping up the to
the maximum for an iSCSI Initiator SCSI port name of 264 bytes?

> 
> Also the SCSI subsystem has tended to hide the the initiator's
> own identifier (this is usually id 7 on the SCSI parallel bus).
> For iSCSI it may be worthwhile to make the initiator port 
> identifier visible in driverfs.
> 

Agreed.

> There is also the case where you want a box to appear to
> the network as an iSCSI target. In this case once a iSCSI
> login is complete you might want to represent the initiator
> in the driverfs tree. For iSCSI, the initiator port identifier 
> is a WWUI plus a 6 byte "inititator session id" for a total
> of 262 bytes.
> 

Now this would be interesting,  although I am not sure how useful
this would be if the user cannot see the entire iSCSI network or if this
would not be better left to userspace.  But of course that is out of the
scope of driverfs.

> So the "target id" we put in driverfs could have one of
> these suggested formats:
>    <number>              - 0 to 1 for ATA
>    <number>              - 0 to 15 for SCSI parallel interface
>    <number>              - 24 bit number for fibre channel
>    <EUI 64+discovery_id> - ieee1394
>    <???>                 - usb (mass storage + scanner)
>    <WWUI> ":" <num>      - iSCSI   [something better than ":"?]
> 

What does the ":" <num> represent?  Would not each <WWUI> directory
contain the devices which are currently in use from that iSCSI target
node?  

> 
> We should also be moving towards 8 byte luns which in one
> descriptor format are a 4 level hierarchy (2 bytes at each
> level).

<nod>
> 
> Doug Gilbert
> 
Thanks,
		Nicholas Bellinger			

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> So the "target id" we put in driverfs could have one of
> these suggested formats:
>    <number>              - 0 to 1 for ATA
>    <number>              - 0 to 15 for SCSI parallel interface
>    <number>              - 24 bit number for fibre channel
>    <EUI 64+discovery_id> - ieee1394
>    <???>                 - usb (mass storage + scanner)
>    <WWUI> ":" <num>      - iSCSI   [something better than ":"?]

In the physical device tree, what's wrong with setting the name to 
something simple, like 'iscsi0', etc. All you're looking for is 
a locally unique ID. 

You need a globally unique ID to do persitant attribute setting and 
restoration, including naming. When /sinb/hotplug gets a call to name the 
device, it can look up the GUID to determine what to name the device.

	-pat

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

On Fri, 21 Jun 2002, Oliver Xymoron wrote:

> On Thu, 20 Jun 2002, Patrick Mochel wrote:
> 
> > > But it was entierly behind me how to fit this
> > > in to the sheme other sd@4,0:h,raw
> > > OS-es are using. And finally how would one fit this in to the
> > > partitioning shemes? For the system aprtitions are simply
> > > block devices hanging off the corresponding block device.
> >
> > Partitions are purely logical entities on a physical disk. They have no
> > presence in the physical device tree.
> 
> As I raised elsewhere in this thread, the distinction between physical and
> logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> disk/tape/whatever as a local device. Ergo, it ought to show up in the
> device tree so that it can be discovered in the same way. But where?

An iSCSI device is a physical device; it just doesn't reside on the local 
system. We should represent the device in some physical form, since the 
logical class mappings do/will assume a mapping to a physical device. 

These devices are essentially children of the network via which they're 
attached. When devices are discovered, I'm assuming you can derive the 
network device through which you're communicating, so you can get enforce 
the ancestral relationship. 

You want the ancestral relationship for several reasons. You'd wouldn't 
power down such a device on PM transitions or during shutdown, but you 
would stop I/O transactions. The drivers for these devices should recogize 
it's a remote device and handlethis. And, if you were to remove the bridge 
device (the network card, etc), you want the devices behind it and their 
logical mappings to go away gracefully.

Mulitpath devices, which you could easily have with multiple routes to the 
same IP address, are another issue that must be addressed. It hasn't yet, 
but we're getting closer...

	-pat

Re: [PATCH] /proc/scsi/map

[Oliver Xymoron]

On Tue, 25 Jun 2002, Patrick Mochel wrote:

>
> On Fri, 21 Jun 2002, Oliver Xymoron wrote:
>
> > On Thu, 20 Jun 2002, Patrick Mochel wrote:
> >
> > > > But it was entierly behind me how to fit this
> > > > in to the sheme other sd@4,0:h,raw
> > > > OS-es are using. And finally how would one fit this in to the
> > > > partitioning shemes? For the system aprtitions are simply
> > > > block devices hanging off the corresponding block device.
> > >
> > > Partitions are purely logical entities on a physical disk. They have no
> > > presence in the physical device tree.
> >
> > As I raised elsewhere in this thread, the distinction between physical and
> > logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> > to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> > stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> > disk/tape/whatever as a local device. Ergo, it ought to show up in the
> > device tree so that it can be discovered in the same way. But where?
>
> An iSCSI device is a physical device; it just doesn't reside on the local
> system. We should represent the device in some physical form, since the
> logical class mappings do/will assume a mapping to a physical device.
>
> These devices are essentially children of the network via which they're
> attached. When devices are discovered, I'm assuming you can derive the
> network device through which you're communicating, so you can get enforce
> the ancestral relationship.

As you note below, it can be available on multiple interfaces. For maximal
confusion, it could be available on a regular NIC and an iSCSI offload
NIC, making it appear as a regular SCSI device (a case to bear in mind,
but one I doubt can be dealt with cleanly).

> You want the ancestral relationship for several reasons. You'd wouldn't
> power down such a device on PM transitions or during shutdown, but you
> would stop I/O transactions. The drivers for these devices should recogize
> it's a remote device and handlethis. And, if you were to remove the bridge
> device (the network card, etc), you want the devices behind it and their
> logical mappings to go away gracefully.

Ok, so what's your take on: NBD (iSCSI without all the SCSI crap),
software RAID, LVM, ramdisk, partitions (a degenerate case of volume
management), loopback, and filesystems. All but the last are block devices
that want to be treated just like disks and will want to know about things
like PM transitions, etc. Filesystems haven't made it into the tree
because we've got that info elsewhere and we've been assuming they're
leafnodes, but if we put loopback devices on top of them, that's no longer
the case. It'd be cleaner globally if this were all explicit in the driver
tree.

> Mulitpath devices, which you could easily have with multiple routes to the
> same IP address, are another issue that must be addressed. It hasn't yet,
> but we're getting closer...

Good to know it's on the radar..

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> > You want the ancestral relationship for several reasons. You'd wouldn't
> > power down such a device on PM transitions or during shutdown, but you
> > would stop I/O transactions. The drivers for these devices should recogize
> > it's a remote device and handlethis. And, if you were to remove the bridge
> > device (the network card, etc), you want the devices behind it and their
> > logical mappings to go away gracefully.
> 
> Ok, so what's your take on: NBD (iSCSI without all the SCSI crap),
> software RAID, LVM, ramdisk, partitions (a degenerate case of volume
> management), loopback, and filesystems. All but the last are block devices
> that want to be treated just like disks and will want to know about things
> like PM transitions, etc. Filesystems haven't made it into the tree
> because we've got that info elsewhere and we've been assuming they're
> leafnodes, but if we put loopback devices on top of them, that's no longer
> the case. It'd be cleaner globally if this were all explicit in the driver
> tree.

This is a topic that has come up several times in the last couple days in 
Ottawa. I don't promise to have a complete solution, but this what I have 
so far:

You have two things: a physical device and a number of logical interfaces
to communicate with the device. iSCSI devices, local disks, video devices, 
mice, and joysticks are all physical devices and deserve a place in the 
device tree. 

RAID, LVM, DRI, and the input layer are all logical interfaces to physical 
devices. The drivers are the conduit between the logical and the physical. 
Drivers register devices with the logical interfcaces as their attached. 
It's up to the driver to register with the interfaces, which they already 
do. If registration gets generalized and centralized, you get internal 
linkage between the interfaces and the devices. This is essentially the 
device class voodoo that I've been talking about. 

Concerning power management, if we have a list of interfaces, and each had 
a suspend callback, you could notify the interfaces before you walked the 
device tree. Maybe this could take care of verifying the devices can 
suspend and failing if it's doing I/O that's too important to stop. 

[ We could also create a swap interface that we skip over when we notify 
these interfaces. Then we walk the tree and save state to the swap 
devices. Then, tell the swap devices to suspend, which can notify the 
devices to actually go to sleep....maybe..]

	-pat

Re: [PATCH] /proc/scsi/map

[Pavel Machek]

Hi!

> [ We could also create a swap interface that we skip over when we notify 
> these interfaces. Then we walk the tree and save state to the swap 
> devices. Then, tell the swap devices to suspend, which can notify the 
> devices to actually go to sleep....maybe..]

No.

swsusp works like this

	stop all devices
	save state
	atomically copy memory into my_big_buffer
	start all devices
	write my_big_buffer into swap
	poweroff

It does not need explicit knowledge of where swap is. And I believe it
is reasonable that way.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH] /proc/scsi/map

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 8963 bytes --]

Hi Linus,

On Thu, Jun 20, 2002 at 08:34:40AM -0700, Linus Torvalds wrote:
> On Thu, 20 Jun 2002, Kurt Garloff wrote:
> > Look at /proc/scsi/scsi: The information is useful for the reader who wants
> > to know what devices he has and were found by the SCSI subsystem.
> 
> I would rephrase that as "the information is only useful to find devices
> found by the SCSI midlayer".

But finding is limited to get a list of manufacturer/model names and their
current CBTU location. You can't make up a device node from that. Only with
a lot of code you arrive at semi-reliable information.

> And my point is that you don't make it any better. Your patch perpetuates
> this lopsided world-view that people should care. THAT is the fundamental
> part that I don't like, because it drags us down for the future.

Actually, with the important exception of IDE disks, most devices are SCSI
in some way, meaning that they understand the SCSI command set. ATAPI
devices are, USB-storage is, IEEE1394 devices are ... so it is not as
restricted as it may seem.
So our consolidated driver structure will IMHO look like this
 
    0        1              2            3

  disk -->  IDE-disk --> IDE mid(?)--> IDE-low
       \-> SCSI-disk --> SCSI-mid  --> SCSI-low
                     |             \-> FC-low
                     \-> USB-mid   --> USB-low
		     \-> FW-mid    --> FW-low
		     \-> pport-mid --> pport-low
		      ....

  cdrom -> SCSI-cd   --> SCSI-mid  --> SCSI-low
                     \-> IDE-mid   --> IDE-low
		      ....
 
   
The drivers at column 0 would implement the interface to userspace vie the
device nodes. column 1 would generate the commands. column 2 would more or
less be some helper/transport layer whereas 3 would talk to the hardware.
And probably there will be some generalized "linux" command set being used
between 0 and 1, which would further down the chain be converted to the real
low-level commands. (We actually already have such a thing for block devs.)
So at level 1 there would be a more general "linux cmd set to XXX cmd set
converter".

Now, userspace should really not care what sort of device is hiding behind a
"disk" device, except that we 
(1) want to be able to identify and find back a device
   (a) by a path to it                  and/or
   (b) by a unique hardware identifier  and/or
   (c) by its content (a label on it)
(2) may want to be able to send low-level (SCSI mostly) commands for
    configuration  to inquire speical information, or to do things where no
    kernel driver support exists, such as scanning or writing CDs.
    For SCSI-like devices, we always want to use sg for this, IMHO,
    as open() on a sg device is without side-effects and works reliably.

For the above, we only have partial solutions, currently.
(1a) The /driverfs path is exposing how a device is connected
     (Similar to the CBTU tuple, but more general and more reliable.)
     Unfortunately, this is 2.5 only.
(1b) We would need to get some WWN or serial number from the device.
     Unfortunately, not all devices have such a thing; currently
     we need userspace tools (see (2)) to collect such info or
     rely on the low-level driver
(1c) UUID and LVM make use of this, but that's a disk-only thing.
(2)  We currently have no relation between e.g. a disk and a sg device, so
     we lost. We can try to collect this info in userspace programs, but
     it's tedious, error prone and not reliable at this moment.

I hope we will have good solutions for all of these in future.

The reason why we want at least (1a) and one of (1b)/(1c) is that we can
have a device connected to a computer more than once (multipathing).

Some devices offer more than one interface; if a kernel-driver for writing
CDs would exist, we would have both a writer and cdrom driver attached to it.
The fact that it's the same piece of hardware also would need to be reflected
in some way. 

For now, lots of devices hook into the the SCSI subsystem, and what I'm
trying to get is a solution for (2) which also enable userspace solutions
for (1b).

[...]
> I will bet you that there are more IDE CD-RW's out there than there are
> SCSI devices. The fact that people use ide-scsi to write to them is a
> hopefully very temporary situation, and the command interface is going
> to move to a higher layer.

They use SCSI commands, so you will want to offer an interface for
applications to send SCSI commands, unless you want somebody to write a
kernel driver to support CD writing.
This would in my "SCSI-centric world-view" also be a SCSI interface, though
maybe not based on nowadays SCSI mid-layer code.

> At which point your SCSI-centric world-view now became a total failure, as
> it no longer shows up most of the devices that can write CD's or DVD's any
> more.
> 
> Sure, it will still continue to show "what devices were found by the SCSI
> midlayer". But user applications will have to scan other stuff, and find
> the IDE-specific stuff, and then whatever else is out there.
> 
> See the problem?

I imagine that we will continue to allow userspace to send raw commands to
devices, as we won't be able nor willing to support every device type fully
by kernel drivers.
These raw commands will be SCSI commands for most devices.
I imagined, that we register all those devices within some subsystem
which would be a revised, generalized and probably thinner SCSI subsystem.

> If, on the other hand, you try to take the bull by the horns and realize
> that the notion of "searching for devices" has nothing to do with SCSI at
> _all_, you may find yourself with more work on your hands, but on the
> other hand, wouldn't it be just so _nice_ to be able to do
> 
> 	find /devices -name cd-rw
> 
> to find all cd-rw's in the system?

Which makes we wonder whether we'll present devices by their attachment path
or by their type or both ....
But yes, it would be nice.

> Does it work that way now? Absolutely not. 
> But most of the infrastructure is actually there today. Wouldn't it
> be _nice_ if after the CD-writing app has found all cd-rw's, it just opens
> them, and the kernel will automatically open the right device (whether it
> is a scsi-generic one or a IDE one)?

See, I would both call SCSI devices. Just because you use a 40/80 pin IDE
cable and a somewhat different low-level protocol, it still understands
SCSI commands.

[...]
> > And completely useless for any program that wants to find a scanner,
> > CD-Writer, ... as there is no connection to the high-level drivers attached
> > to them.
> 
> I'm not disputing that.
> 
> However, I _am_ disputing that this should be done in some SCSI-centric
> way that works for SCSI but nothing else.

I would have imagined driver unification as making all devices that
understand SCSI commands to hook into some generalized and cleaned SCSI
subsystem.
Obviously your vision (or only naming?) is different.
How does it look like in your plans?

> When I want to find a CD-ROM, I don't want to worry about whether it is
> IDE or SCSI. I would
> 
> > But I still think the SCSI subsystem should report which SCSI (low-level)
> > device is mapped to what high-level driver.
> > Would you accept a patch that adds a line like
> >
> > Host: scsi3 Channel: 00 Id: 12 Lun: 00
> >   Vendor: IBM      Model: DPSS-336950N     Rev: S84D
> >   Type:   Direct-Access                    ANSI SCSI revision: 03
> >   Attached drivers: sg12(c:15:0c) sdf(b:08:50)
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > to /proc/scsi/scsi ?
> 
> That would be less offensive to me if only because it doesn't introduce a
> _new_ interface that is SCSI-only, it only extends on an old one. It makes
> no _technical_ difference, but I'd rather extend an old broken interface
> than introduce a totally new broken interface.

Please consider applying the attached patch which adds this line.

[...]
> > The CBTU tuple uniquely addresses a SCSI device in a running system.
> 
> Yes, but that's not enough. Other people are still asking for physical
> location, so let's try to fix two things with _one_ generic interface that
> is at least agnostic to how a device is connected to the kernel..

That would be the /dev/disks/0 ... N, /dev/cd/0 ... M, ... interface, if I
get you correctly. Instead of 0 ... N one might hope to have unique IDs.

But we would still need to find some way to allow extra information, like
the path there, sending low-level commands, ... as we'll never be able
(nor wanting) to push all into the kernel behind the "disk" interface, I
think ...

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #1.2: scsi-map-8.diff --]
[-- Type: text/plain, Size: 8535 bytes --]

diff -uNr linux-2.5.23-dj2/drivers/scsi/hosts.h linux-2.5.23-dj2-scsirephl/drivers/scsi/hosts.h
--- linux-2.5.23-dj2/drivers/scsi/hosts.h	Thu Jun 20 01:44:47 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/hosts.h	Thu Jun 20 18:54:10 2002
@@ -486,6 +486,7 @@
     void (*detach)(Scsi_Device *);
     int (*init_command)(Scsi_Cmnd *);     /* Used by new queueing code. 
                                            Selects command for blkdevs */
+    int (*find_kdev)(Scsi_Device *, char*, kdev_t*);  /* find back dev. */
 };
 
 void  scsi_initialize_queue(Scsi_Device * SDpnt, struct Scsi_Host * SHpnt);
diff -uNr linux-2.5.23-dj2/drivers/scsi/osst.c linux-2.5.23-dj2-scsirephl/drivers/scsi/osst.c
--- linux-2.5.23-dj2/drivers/scsi/osst.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/osst.c	Thu Jun 20 18:54:26 2002
@@ -155,6 +155,7 @@
 static int osst_attach(Scsi_Device *);
 static int osst_detect(Scsi_Device *);
 static void osst_detach(Scsi_Device *);
+static int osst_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 struct Scsi_Device_Template osst_template =
 {
@@ -166,7 +167,8 @@
        detect:		osst_detect,
        init:		osst_init,
        attach:		osst_attach,
-       detach:		osst_detach
+       detach:		osst_detach,
+       find_kdev:	osst_find_kdev,
 };
 
 static int osst_int_ioctl(OS_Scsi_Tape *STp, Scsi_Request ** aSRpnt, unsigned int cmd_in,unsigned long arg);
@@ -5417,6 +5419,24 @@
 	return 0;
 }
 
+static int osst_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	OS_Scsi_Tape *ostp;
+	
+	if (sdp && sdp->type == TYPE_TAPE && osst_supports(sdp)) {
+		for (ostp = os_scsi_tapes[i = 0]; i < osst_template.dev_max;
+		     ostp = os_scsi_tapes[++i]) {
+			if (ostp && ostp->device == sdp) {
+				sprintf (nm, "osst%i", i);
+				*dev = mk_kdev(OSST_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int osst_attach(Scsi_Device * SDp)
 {
 	OS_Scsi_Tape * tpnt;
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi_proc.c linux-2.5.23-dj2-scsirephl/drivers/scsi/scsi_proc.c
--- linux-2.5.23-dj2/drivers/scsi/scsi_proc.c	Wed Jun 19 04:11:47 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/scsi_proc.c	Thu Jun 20 18:52:55 2002
@@ -260,6 +260,10 @@
 
 	int x, y = *size;
 	extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
+	char nm[16];
+	kdev_t kdev;
+	int att = scd->attached;
+	struct Scsi_Device_Template *sd_t = scsi_devicelist;
 
 	y = sprintf(buffer + len,
 	     "Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n  Vendor: ",
@@ -295,7 +299,24 @@
 		y += sprintf(buffer + len + y, " CCS\n");
 	else
 		y += sprintf(buffer + len + y, "\n");
+	
+	/* Report high level devices attached */
+	y += sprintf (buffer + len + y, "  Attached drivers:");
 
+	while (att && sd_t) {
+		if (sd_t->find_kdev) {
+			if (!(sd_t->find_kdev(scd, nm, &kdev))) {
+				y += sprintf(buffer + len + y,
+					     " %s(%c:%02x:%02x)",
+					     nm, (sd_t->blk? 'b': 'c'),
+					     MAJOR(kdev), MINOR(kdev));
+				--att;
+			}
+		}
+		sd_t = sd_t->next;
+	}
+
+	y += sprintf(buffer + len + y, "\n");
 	*size = y;
 	return;
 }
diff -uNr linux-2.5.23-dj2/drivers/scsi/sd.c linux-2.5.23-dj2-scsirephl/drivers/scsi/sd.c
--- linux-2.5.23-dj2/drivers/scsi/sd.c	Thu Jun 20 01:44:48 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/sd.c	Thu Jun 20 18:54:43 2002
@@ -103,6 +103,7 @@
 static int sd_detect(Scsi_Device *);
 static void sd_detach(Scsi_Device *);
 static int sd_init_command(Scsi_Cmnd *);
+static int sd_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template sd_template = {
 	module:THIS_MODULE,
@@ -122,6 +123,7 @@
 	attach:sd_attach,
 	detach:sd_detach,
 	init_command:sd_init_command,
+	find_kdev:sd_find_kdev,
 };
 
 static void sd_rw_intr(Scsi_Cmnd * SCpnt);
@@ -285,6 +287,24 @@
 	}
 }
 
+static int sd_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_Disk *sdkp;
+	int dsk_nr;
+
+	if (sdp && (sdp->type == TYPE_DISK || sdp->type == TYPE_MOD)) {
+		for (dsk_nr = 0; dsk_nr < sd_template.dev_max; ++dsk_nr) {
+			sdkp = sd_dsk_arr[dsk_nr];
+			if (sdkp->device == sdp) {
+				sd_dskname(dsk_nr, nm);
+				*dev = MKDEV_SD(dsk_nr);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 /**
  *	sd_find_queue - yields queue associated with device
  *	@dev: kernel device descriptor (kdev_t)
diff -uNr linux-2.5.23-dj2/drivers/scsi/sg.c linux-2.5.23-dj2-scsirephl/drivers/scsi/sg.c
--- linux-2.5.23-dj2/drivers/scsi/sg.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/sg.c	Thu Jun 20 18:54:51 2002
@@ -111,6 +111,7 @@
 static void sg_finish(void);
 static int sg_detect(Scsi_Device *);
 static void sg_detach(Scsi_Device *);
+static int sg_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 static Scsi_Request * dummy_cmdp;	/* only used for sizeof */
 
@@ -120,6 +121,7 @@
 static struct Scsi_Device_Template sg_template =
 {
       module:THIS_MODULE,
+      name:"generic",
       tag:"sg",
       scsi_type:0xff,
       major:SCSI_GENERIC_MAJOR,
@@ -127,7 +129,8 @@
       init:sg_init,
       finish:sg_finish,
       attach:sg_attach,
-      detach:sg_detach
+      detach:sg_detach,
+      find_kdev:sg_find_kdev
 };
 
 
@@ -2632,6 +2635,37 @@
 }
 
 #ifdef CONFIG_PROC_FS
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    unsigned long iflags;
+    int err = 1; 
+
+    if (sdp && sg_dev_arr) {
+	int k;
+	read_lock_irqsave(&sg_dev_arr_lock, iflags);
+	for (k = 0; k < sg_template.dev_max; ++k) {
+	    if (sg_dev_arr[k] && sg_dev_arr[k]->device == sdp) {
+		sprintf (nm, "sg%i", k);
+	        *dev = sg_dev_arr[k]->i_rdev;
+		err = 0;
+		break;
+	    }
+	}
+	read_unlock_irqrestore(&sg_dev_arr_lock, iflags);
+    }
+    return err;
+}
+#else
+/* Not needed without procfs support */
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    *nm = 0;
+    *kdev = NODEV;
+    return 1;
+}
+#endif
+
+#ifdef CONFIG_PROC_FS
 
 static struct proc_dir_entry * sg_proc_sgp = NULL;
 
diff -uNr linux-2.5.23-dj2/drivers/scsi/sr.c linux-2.5.23-dj2-scsirephl/drivers/scsi/sr.c
--- linux-2.5.23-dj2/drivers/scsi/sr.c	Wed Jun 19 04:11:50 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/sr.c	Thu Jun 20 18:54:59 2002
@@ -71,6 +71,8 @@
 
 static int sr_init_command(Scsi_Cmnd *);
 
+static int sr_find_kdev(Scsi_Device*, char*, kdev_t*);
+
 static struct Scsi_Device_Template sr_template =
 {
 	module:THIS_MODULE,
@@ -84,7 +86,8 @@
 	finish:sr_finish,
 	attach:sr_attach,
 	detach:sr_detach,
-	init_command:sr_init_command
+	init_command:sr_init_command,
+	find_kdev:sr_find_kdev,
 };
 
 Scsi_CD *scsi_CDs;
@@ -471,6 +474,23 @@
 	return 0;
 }
 
+static int sr_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_CD *srp;
+	int i;
+	
+	if (sdp && (sdp->type == TYPE_ROM || sdp->type == TYPE_WORM)) {
+		for (srp = scsi_CDs, i = 0; i < sr_template.dev_max;
+		     ++i, ++srp) {
+			if (srp->device == sdp) {
+				sprintf(nm, "sr%i", i);
+				*dev = mk_kdev(SCSI_CDROM_MAJOR,i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
 
 void get_sectorsize(int i)
 {
diff -uNr linux-2.5.23-dj2/drivers/scsi/st.c linux-2.5.23-dj2-scsirephl/drivers/scsi/st.c
--- linux-2.5.23-dj2/drivers/scsi/st.c	Wed Jun 19 04:11:56 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/st.c	Thu Jun 20 18:56:18 2002
@@ -148,6 +148,7 @@
 static int st_attach(Scsi_Device *);
 static int st_detect(Scsi_Device *);
 static void st_detach(Scsi_Device *);
+static int st_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template st_template = {
 	module:		THIS_MODULE,
@@ -157,7 +158,8 @@
 	major:		SCSI_TAPE_MAJOR, 
 	detect:		st_detect, 
 	attach:		st_attach, 
-	detach:		st_detach
+	detach:		st_detach,
+	find_kdev:	st_find_kdev
 };
 
 static int st_compression(Scsi_Tape *, int);
@@ -3760,6 +3762,24 @@
 	return;
 }
 
+static int st_find_kdev(Scsi_Device * sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	Scsi_Tape *stp;
+
+	if (sdp && sdp->type == TYPE_TAPE && !st_incompatible(sdp)) {
+		for (stp = scsi_tapes[0], i = 0; i < st_template.dev_max;
+		     stp = scsi_tapes[++i]) {
+			if (stp && stp->device == sdp) {
+				sprintf(nm, "st%i", i);
+				*dev = mk_kdev(SCSI_TAPE_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int __init init_st(void)
 {
 	validate_options();

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Kurt Garloff wrote:
>
> Actually, with the important exception of IDE disks, most devices are SCSI
> in some way

Don't be silly.

You appear to have a very disk-centric world view, and you seem to ignore
that even in disks, the large majority is IDE, and with SCSI prices not
coming down, that's going to be only more and more true.

Also, most disk devices are using SCSI _command_sets_. But that does not
translate to "using the SCSI mid-layer".

> So our consolidated driver structure will IMHO look like this

The way it seems to be going right now is:

 - stage 1: minor/major -> "queue + index" mapping
   (only done at "open()" time, the internal kernel is trying to get rid
   of most of the major/minor stuff)

 - stage 2: ll_rw_block.c, ioctl.c: insert command on queue.

   Yes, this layer builds up SCSI commands, but it doesn't actually have
   anything to do with the SCSI midlayer.

 - stage 3: driver takes it off the queue and executes the thing.

In short, what is happening is that the SCSI mid-layer to some degree
becomes _less_ relevant, exactly because the SCSI _command_ structure has
gotten so universal that that part is moved up one layer into the generic
part.

Which means that things like ide-scsi etc just don't make any sense any
more. Your assumption that SCSI-cd would take over the IDE layer is just
_wrong_. It's going the other way. There shouldn't be any real difference
between "disk" and "cdrom", you just send commands down the queue.

> Now, userspace should really not care what sort of device is hiding behind a
> "disk" device, except that we
> (1) want to be able to identify and find back a device
>    (a) by a path to it                  and/or
>    (b) by a unique hardware identifier  and/or
>    (c) by its content (a label on it)

Absolutely.

> (2) may want to be able to send low-level (SCSI mostly) commands for
>     configuration  to inquire speical information, or to do things where no
>     kernel driver support exists, such as scanning or writing CDs.
>     For SCSI-like devices, we always want to use sg for this, IMHO,
>     as open() on a sg device is without side-effects and works reliably.

I think we should get _away_ from those silly "sg" devices. The whole
notion that there are "sg" vs "sr" vs "sd" devices is a total bogosity,
and should just go away. What's the point of having those things? It only
confuses people.

We should open a disk device, and access it. Nothing else. The fact that
SCSI got the notion that sd/sr/sg are somehow different is just one of the
_problems_ in the SCSI layer. It's just a queue to send commands to
together with the data and the result, that's all it ever was.

(In other words, I kind of agree with your characterization that "we
should always use 'sg'" because clearly that's the closest of the SCSI
devices to the notion of a command queue. However, I think you've stared
at SCSI so long that you think that that split-up makes sense, when it
really doesn't).

> > I will bet you that there are more IDE CD-RW's out there than there are
> > SCSI devices. The fact that people use ide-scsi to write to them is a
> > hopefully very temporary situation, and the command interface is going
> > to move to a higher layer.
>
> They use SCSI commands, so you will want to offer an interface for
> applications to send SCSI commands, unless you want somebody to write a
> kernel driver to support CD writing.

SCSI commands != "SCSI midlayer".

The IDE driver is already moving into the direction that it just accepts a
command off the request queue.

That does _not_ mean that it has anything to do with the SCSI layer, quite
the reverse. It means that we're going _away_ from the SCSI layer, and
that ide-scsi becomes nothing but an embarrassing remnant of history.

		Linus

Re: [PATCH] /proc/scsi/map

[Kurt Garloff]

On Thu, Jun 20, 2002 at 08:32:09PM +0200, Kurt Garloff wrote:
> Please consider applying the attached patch which adds this line.

Updated patch (with MAJOR -> major correction) against 2.5.24 is here.

diff -uNr linux-2.5.24-dj1/drivers/scsi/hosts.h linux-2.5.24-dj1-scsirephl/drivers/scsi/hosts.h
--- linux-2.5.24-dj1/drivers/scsi/hosts.h	Fri Jun 21 07:51:45 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/hosts.h	Fri Jun 21 08:22:27 2002
@@ -486,6 +486,7 @@
     void (*detach)(Scsi_Device *);
     int (*init_command)(Scsi_Cmnd *);     /* Used by new queueing code. 
                                            Selects command for blkdevs */
+    int (*find_kdev)(Scsi_Device *, char*, kdev_t*);  /* find back dev. */
 };
 
 void  scsi_initialize_queue(Scsi_Device * SDpnt, struct Scsi_Host * SHpnt);
diff -uNr linux-2.5.24-dj1/drivers/scsi/osst.c linux-2.5.24-dj1-scsirephl/drivers/scsi/osst.c
--- linux-2.5.24-dj1/drivers/scsi/osst.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/osst.c	Fri Jun 21 08:22:27 2002
@@ -155,6 +155,7 @@
 static int osst_attach(Scsi_Device *);
 static int osst_detect(Scsi_Device *);
 static void osst_detach(Scsi_Device *);
+static int osst_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 struct Scsi_Device_Template osst_template =
 {
@@ -166,7 +167,8 @@
        detect:		osst_detect,
        init:		osst_init,
        attach:		osst_attach,
-       detach:		osst_detach
+       detach:		osst_detach,
+       find_kdev:	osst_find_kdev,
 };
 
 static int osst_int_ioctl(OS_Scsi_Tape *STp, Scsi_Request ** aSRpnt, unsigned int cmd_in,unsigned long arg);
@@ -5417,6 +5419,24 @@
 	return 0;
 }
 
+static int osst_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	OS_Scsi_Tape *ostp;
+	
+	if (sdp && sdp->type == TYPE_TAPE && osst_supports(sdp)) {
+		for (ostp = os_scsi_tapes[i = 0]; i < osst_template.dev_max;
+		     ostp = os_scsi_tapes[++i]) {
+			if (ostp && ostp->device == sdp) {
+				sprintf (nm, "osst%i", i);
+				*dev = mk_kdev(OSST_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int osst_attach(Scsi_Device * SDp)
 {
 	OS_Scsi_Tape * tpnt;
diff -uNr linux-2.5.24-dj1/drivers/scsi/scsi_proc.c linux-2.5.24-dj1-scsirephl/drivers/scsi/scsi_proc.c
--- linux-2.5.24-dj1/drivers/scsi/scsi_proc.c	Wed Jun 19 04:11:47 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/scsi_proc.c	Fri Jun 21 08:21:44 2002
@@ -260,6 +260,10 @@
 
 	int x, y = *size;
 	extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
+	char nm[16];
+	kdev_t kdev;
+	int att = scd->attached;
+	struct Scsi_Device_Template *sd_t = scsi_devicelist;
 
 	y = sprintf(buffer + len,
 	     "Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n  Vendor: ",
@@ -295,7 +299,24 @@
 		y += sprintf(buffer + len + y, " CCS\n");
 	else
 		y += sprintf(buffer + len + y, "\n");
+	
+	/* Report high level devices attached */
+	y += sprintf (buffer + len + y, "  Attached drivers:");
 
+	while (att && sd_t) {
+		if (sd_t->find_kdev) {
+			if (!(sd_t->find_kdev(scd, nm, &kdev))) {
+				y += sprintf(buffer + len + y,
+					     " %s(%c:%02x:%02x)",
+					     nm, (sd_t->blk? 'b': 'c'),
+					     major(kdev), minor(kdev));
+				--att;
+			}
+		}
+		sd_t = sd_t->next;
+	}
+
+	y += sprintf(buffer + len + y, "\n");
 	*size = y;
 	return;
 }
diff -uNr linux-2.5.24-dj1/drivers/scsi/sd.c linux-2.5.24-dj1-scsirephl/drivers/scsi/sd.c
--- linux-2.5.24-dj1/drivers/scsi/sd.c	Fri Jun 21 07:51:45 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/sd.c	Fri Jun 21 08:22:27 2002
@@ -103,6 +103,7 @@
 static int sd_detect(Scsi_Device *);
 static void sd_detach(Scsi_Device *);
 static int sd_init_command(Scsi_Cmnd *);
+static int sd_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template sd_template = {
 	module:THIS_MODULE,
@@ -122,6 +123,7 @@
 	attach:sd_attach,
 	detach:sd_detach,
 	init_command:sd_init_command,
+	find_kdev:sd_find_kdev,
 };
 
 static void sd_rw_intr(Scsi_Cmnd * SCpnt);
@@ -285,6 +287,24 @@
 	}
 }
 
+static int sd_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_Disk *sdkp;
+	int dsk_nr;
+
+	if (sdp && (sdp->type == TYPE_DISK || sdp->type == TYPE_MOD)) {
+		for (dsk_nr = 0; dsk_nr < sd_template.dev_max; ++dsk_nr) {
+			sdkp = sd_dsk_arr[dsk_nr];
+			if (sdkp->device == sdp) {
+				sd_dskname(dsk_nr, nm);
+				*dev = MKDEV_SD(dsk_nr);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 /**
  *	sd_find_queue - yields queue associated with device
  *	@dev: kernel device descriptor (kdev_t)
diff -uNr linux-2.5.24-dj1/drivers/scsi/sg.c linux-2.5.24-dj1-scsirephl/drivers/scsi/sg.c
--- linux-2.5.24-dj1/drivers/scsi/sg.c	Fri Jun 21 07:51:45 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/sg.c	Fri Jun 21 08:22:27 2002
@@ -111,6 +111,7 @@
 static void sg_finish(void);
 static int sg_detect(Scsi_Device *);
 static void sg_detach(Scsi_Device *);
+static int sg_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 static Scsi_Request * dummy_cmdp;	/* only used for sizeof */
 
@@ -120,6 +121,7 @@
 static struct Scsi_Device_Template sg_template =
 {
       module:THIS_MODULE,
+      name:"generic",
       tag:"sg",
       scsi_type:0xff,
       major:SCSI_GENERIC_MAJOR,
@@ -127,7 +129,8 @@
       init:sg_init,
       finish:sg_finish,
       attach:sg_attach,
-      detach:sg_detach
+      detach:sg_detach,
+      find_kdev:sg_find_kdev
 };
 
 
@@ -2674,6 +2677,37 @@
 }
 
 #ifdef CONFIG_PROC_FS
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    unsigned long iflags;
+    int err = 1; 
+
+    if (sdp && sg_dev_arr) {
+	int k;
+	read_lock_irqsave(&sg_dev_arr_lock, iflags);
+	for (k = 0; k < sg_template.dev_max; ++k) {
+	    if (sg_dev_arr[k] && sg_dev_arr[k]->device == sdp) {
+		sprintf (nm, "sg%i", k);
+	        *dev = sg_dev_arr[k]->i_rdev;
+		err = 0;
+		break;
+	    }
+	}
+	read_unlock_irqrestore(&sg_dev_arr_lock, iflags);
+    }
+    return err;
+}
+#else
+/* Not needed without procfs support */
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    *nm = 0;
+    *kdev = NODEV;
+    return 1;
+}
+#endif
+
+#ifdef CONFIG_PROC_FS
 
 static struct proc_dir_entry * sg_proc_sgp = NULL;
 
diff -uNr linux-2.5.24-dj1/drivers/scsi/sr.c linux-2.5.24-dj1-scsirephl/drivers/scsi/sr.c
--- linux-2.5.24-dj1/drivers/scsi/sr.c	Wed Jun 19 04:11:50 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/sr.c	Fri Jun 21 08:22:27 2002
@@ -71,6 +71,8 @@
 
 static int sr_init_command(Scsi_Cmnd *);
 
+static int sr_find_kdev(Scsi_Device*, char*, kdev_t*);
+
 static struct Scsi_Device_Template sr_template =
 {
 	module:THIS_MODULE,
@@ -84,7 +86,8 @@
 	finish:sr_finish,
 	attach:sr_attach,
 	detach:sr_detach,
-	init_command:sr_init_command
+	init_command:sr_init_command,
+	find_kdev:sr_find_kdev,
 };
 
 Scsi_CD *scsi_CDs;
@@ -471,6 +474,23 @@
 	return 0;
 }
 
+static int sr_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_CD *srp;
+	int i;
+	
+	if (sdp && (sdp->type == TYPE_ROM || sdp->type == TYPE_WORM)) {
+		for (srp = scsi_CDs, i = 0; i < sr_template.dev_max;
+		     ++i, ++srp) {
+			if (srp->device == sdp) {
+				sprintf(nm, "sr%i", i);
+				*dev = mk_kdev(SCSI_CDROM_MAJOR,i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
 
 void get_sectorsize(int i)
 {
diff -uNr linux-2.5.24-dj1/drivers/scsi/st.c linux-2.5.24-dj1-scsirephl/drivers/scsi/st.c
--- linux-2.5.24-dj1/drivers/scsi/st.c	Wed Jun 19 04:11:56 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/st.c	Fri Jun 21 08:22:27 2002
@@ -148,6 +148,7 @@
 static int st_attach(Scsi_Device *);
 static int st_detect(Scsi_Device *);
 static void st_detach(Scsi_Device *);
+static int st_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template st_template = {
 	module:		THIS_MODULE,
@@ -157,7 +158,8 @@
 	major:		SCSI_TAPE_MAJOR, 
 	detect:		st_detect, 
 	attach:		st_attach, 
-	detach:		st_detach
+	detach:		st_detach,
+	find_kdev:	st_find_kdev
 };
 
 static int st_compression(Scsi_Tape *, int);
@@ -3760,6 +3762,24 @@
 	return;
 }
 
+static int st_find_kdev(Scsi_Device * sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	Scsi_Tape *stp;
+
+	if (sdp && sdp->type == TYPE_TAPE && !st_incompatible(sdp)) {
+		for (stp = scsi_tapes[0], i = 0; i < st_template.dev_max;
+		     stp = scsi_tapes[++i]) {
+			if (stp && stp->device == sdp) {
+				sprintf(nm, "st%i", i);
+				*dev = mk_kdev(SCSI_TAPE_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int __init init_st(void)
 {
 	validate_options();



Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security