Re: [PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] (Jonathan Lundell) wrote on 11.05.01 in : > At 1:32 PM -0300 2001-05-11, Ralf Baechle wrote: > >On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: > >> Kai Henningsen wrote: > >> >What's a lot more important is that the mail standards say that this > >>

Re: [PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] (Jonathan Lundell) wrote on 11.05.01 in p0510030db7221c090810@[10.128.7.49]·2: At 1:32 PM -0300 2001-05-11, Ralf Baechle wrote: On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: Kai Henningsen wrote: What's a lot more important is that the mail

Re: [PATCH] adding PCI bus information to SCSI layer

At 11:20 PM -0300 2001-05-11, Ralf Baechle wrote: >On Fri, May 11, 2001 at 03:49:05PM -0700, Jonathan Lundell wrote: > >It's 998 plus a CR/LF sequence which is 1000 bytes, not exactly an odd >number. And it's the official successor of RFC 822 which was an official >STD. What I meant by

Re: [PATCH] adding PCI bus information to SCSI layer

On Fri, May 11, 2001 at 03:49:05PM -0700, Jonathan Lundell wrote: > >> >If you want to support wrapping with plain text, investigate > >> >format=flowed. > >> > >> Yes, I did that. > >> > > > I'm curious, though: I haven't found the mail standards that forbid > >> receivers to wrap long

Re: [PATCH] adding PCI bus information to SCSI layer

> >> > > > I'm curious, though: I haven't found the mail standards that forbid > >> receivers to wrap long lines. Certainly many mail clients do it. > >> What's the relevant RFC? > > > >RFC 2822, 2.1.1. > > Thanks. It's not quite a standard yet, but it's true, it does limit > lines to 998

Re: [PATCH] adding PCI bus information to SCSI layer

At 1:32 PM -0300 2001-05-11, Ralf Baechle wrote: >On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: >> Kai Henningsen wrote: >> >What's a lot more important is that the mail standards say that this stuff >> >should not be interpreted by the receivers as needing wrapping, so >>

Re: [PATCH] adding PCI bus information to SCSI layer

On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: > >What's a lot more important is that the mail standards say that this stuff > >should not be interpreted by the receivers as needing wrapping, so > >irregardless of good or bad design it's just plain illegal. > > > >If you

Re: [PATCH] adding PCI bus information to SCSI layer

On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: What's a lot more important is that the mail standards say that this stuff should not be interpreted by the receivers as needing wrapping, so irregardless of good or bad design it's just plain illegal. If you want to

Re: [PATCH] adding PCI bus information to SCSI layer

At 1:32 PM -0300 2001-05-11, Ralf Baechle wrote: On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote: Kai Henningsen wrote: What's a lot more important is that the mail standards say that this stuff should not be interpreted by the receivers as needing wrapping, so

Re: [PATCH] adding PCI bus information to SCSI layer

I'm curious, though: I haven't found the mail standards that forbid receivers to wrap long lines. Certainly many mail clients do it. What's the relevant RFC? RFC 2822, 2.1.1. Thanks. It's not quite a standard yet, but it's true, it does limit lines to 998 characters. Sort of a

Re: [PATCH] adding PCI bus information to SCSI layer

On Fri, May 11, 2001 at 03:49:05PM -0700, Jonathan Lundell wrote: If you want to support wrapping with plain text, investigate format=flowed. Yes, I did that. I'm curious, though: I haven't found the mail standards that forbid receivers to wrap long lines. Certainly many mail

Re: [PATCH] adding PCI bus information to SCSI layer

At 11:20 PM -0300 2001-05-11, Ralf Baechle wrote: On Fri, May 11, 2001 at 03:49:05PM -0700, Jonathan Lundell wrote: It's 998 plus a CR/LF sequence which is 1000 bytes, not exactly an odd number. And it's the official successor of RFC 822 which was an official STD. What I meant by strange was

Re: [PATCH] adding PCI bus information to SCSI layer

> open("/dev/ttyF00/speed=9600,clocal"); > > is illegal. That may be a nice way to get much of the desired behaviour without > totally breaking compatibility > > Linus has suggested we do something similar in 2.5.x for multiple > data streams (or forks) in certain filesystems

Re: [PATCH] adding PCI bus information to SCSI layer

At 9:32 AM +0200 2001-05-03, Kai Henningsen wrote: >[EMAIL PROTECTED] (Jonathan Lundell) wrote on 26.04.01 in >: > >> At 10:31 PM -0600 2001-04-26, Richard Gooch wrote: >> >BTW: please fix your mailer to do linewrap at 72 characters. Your >> >lines are

Re: [PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] (Jonathan Lundell) wrote on 26.04.01 in : > At 10:31 PM -0600 2001-04-26, Richard Gooch wrote: > >BTW: please fix your mailer to do linewrap at 72 characters. Your > >lines are hundreds of characters long, and that's hard to read. > >

Re: [PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] (Jonathan Lundell) wrote on 26.04.01 in p05100303b70eadd613b0@[207.213.214.37]: At 10:31 PM -0600 2001-04-26, Richard Gooch wrote: BTW: please fix your mailer to do linewrap at 72 characters. Your lines are hundreds of characters long, and that's hard to read. Sorry for

Re: [PATCH] adding PCI bus information to SCSI layer

At 9:32 AM +0200 2001-05-03, Kai Henningsen wrote: [EMAIL PROTECTED] (Jonathan Lundell) wrote on 26.04.01 in p05100303b70eadd613b0@[207.213.214.37]: At 10:31 PM -0600 2001-04-26, Richard Gooch wrote: BTW: please fix your mailer to do linewrap at 72 characters. Your lines are hundreds of

Re: [PATCH] adding PCI bus information to SCSI layer

open(/dev/ttyF00/speed=9600,clocal); is illegal. That may be a nice way to get much of the desired behaviour without totally breaking compatibility Linus has suggested we do something similar in 2.5.x for multiple data streams (or forks) in certain filesystems sugh as

Re: [PATCH] adding PCI bus information to SCSI layer

> 1. Does POSIX state, that "/" is the directory/entry[1] separator? > 2. Can a device node be an directory? > > If 1. and not 2., there is no way to implement it like that. Why not. It doesn't say what happens if there is pathname left over when you hit the device specifically. tar would

Re: [PATCH] adding PCI bus information to SCSI layer

On Tue, May 01, 2001 at 09:32:41PM +0100, Alan Cox wrote: > Having thought over the issues I plan to maintain a 32bit dev_t kernel with > conventional mknod behaviour, even if Linus won't. One very interesting item > that Peter Anvin noted is that its not clear in POSIX that > > mknod

Re: [PATCH] adding PCI bus information to SCSI layer

On Tue, May 01, 2001 at 09:32:41PM +0100, Alan Cox wrote: Having thought over the issues I plan to maintain a 32bit dev_t kernel with conventional mknod behaviour, even if Linus won't. One very interesting item that Peter Anvin noted is that its not clear in POSIX that mknod

Re: [PATCH] adding PCI bus information to SCSI layer

1. Does POSIX state, that / is the directory/entry[1] separator? 2. Can a device node be an directory? If 1. and not 2., there is no way to implement it like that. Why not. It doesn't say what happens if there is pathname left over when you hit the device specifically. tar would archive

Re: [PATCH] adding PCI bus information to SCSI layer

> I'm wary of this, because Linus has stated that the current "struct > pci_dev" is really meant to be a generic thing, and it might change to > "struct dev" (now that we've renamed the old "struct dev" to "struct > netdev"). It is already being (ab)used this way. Its an isa pnp device in 2.4.*.

Re: [PATCH] adding PCI bus information to SCSI layer

Ingo Oeser writes: > On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote: > > Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0 > > What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead? > > That way we could hook roots of busses (which are "." nodes, like > if

Re: [PATCH] adding PCI bus information to SCSI layer

At 7:27 PM -0600 2001-04-30, Richard Gooch wrote: >Jonathan Lundell writes: > > ... > > Consider, instead of /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 >> something like >> >> /dev/bus/pci0d1f0/scsi0t1l2p3 >> or >> /dev/bus/pci0:d1:f0/scsi0:t1:l2:p3 > >Nope. Linus hates the idea of

Re: [PATCH] adding PCI bus information to SCSI layer

On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote: > Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0 What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead? That way we could hook roots of busses (which are "." nodes, like if they where mounted independently)

Re: [PATCH] adding PCI bus information to SCSI layer

On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote: Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0 What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead? That way we could hook roots of busses (which are . nodes, like if they where mounted independently)

Re: [PATCH] adding PCI bus information to SCSI layer

At 7:27 PM -0600 2001-04-30, Richard Gooch wrote: Jonathan Lundell writes: ... Consider, instead of /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 something like /dev/bus/pci0d1f0/scsi0t1l2p3 or /dev/bus/pci0:d1:f0/scsi0:t1:l2:p3 Nope. Linus hates the idea of compressed names. He

Re: [PATCH] adding PCI bus information to SCSI layer

Ingo Oeser writes: On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote: Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0 What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead? That way we could hook roots of busses (which are . nodes, like if they where

Re: [PATCH] adding PCI bus information to SCSI layer

I'm wary of this, because Linus has stated that the current struct pci_dev is really meant to be a generic thing, and it might change to struct dev (now that we've renamed the old struct dev to struct netdev). It is already being (ab)used this way. Its an isa pnp device in 2.4.*. Its also a

Re: [PATCH] adding PCI bus information to SCSI layer

Jonathan Lundell writes: > On the subject of the Subject, Jeff Garzik recently (21 March) > suggested adding geographic information to the ethtool interface, > pci_dev->slot_name in the case of a PCI-based interface. There's > something to be said for having a uniform method of identifying the

Re: [PATCH] adding PCI bus information to SCSI layer

Jonathan Lundell writes: On the subject of the Subject, Jeff Garzik recently (21 March) suggested adding geographic information to the ethtool interface, pci_dev-slot_name in the case of a PCI-based interface. There's something to be said for having a uniform method of identifying the

Re: [PATCH] adding PCI bus information to SCSI layer

At 10:31 PM -0600 2001-04-26, Richard Gooch wrote: >BTW: please fix your mailer to do linewrap at 72 characters. Your >lines are hundreds of characters long, and that's hard to read. Sorry for the inconvenience. There are a lot of reasons why I believe it's properly a display function to wrap

Re: [PATCH] adding PCI bus information to SCSI layer

Jonathan Lundell writes: > At 3:59 PM -0600 4/24/01, Richard Gooch wrote: > >The plan I have (which I hope to get started on soon, now that I'm > >back from travels), is to change /dev/scsi/host# from a directory into > >a symbolic link to a directory called: /dev/bus/pci0/slot1/function0. >

Re: [PATCH] adding PCI bus information to SCSI layer

Jonathan Lundell writes: At 3:59 PM -0600 4/24/01, Richard Gooch wrote: The plan I have (which I hope to get started on soon, now that I'm back from travels), is to change /dev/scsi/host# from a directory into a symbolic link to a directory called: /dev/bus/pci0/slot1/function0. Thus, to

Re: [PATCH] adding PCI bus information to SCSI layer

At 3:59 PM -0600 4/24/01, Richard Gooch wrote: >The plan I have (which I hope to get started on soon, now that I'm >back from travels), is to change /dev/scsi/host# from a directory into >a symbolic link to a directory called: /dev/bus/pci0/slot1/function0. >Thus, to access a partition via

Re: [PATCH] adding PCI bus information to SCSI layer

Matt Domsch writes: > Thanks everyone for your input again. I've made the changes suggested, and > would appreciate this being applied to Linus' and Alan's trees. This is > necessary for solving the "what disk does BIOS think is my boot disk" > problem on IA-64, and I hope to extend it to IA-32

[PATCH] adding PCI bus information to SCSI layer

Thanks everyone for your input again. I've made the changes suggested, and would appreciate this being applied to Linus' and Alan's trees. This is necessary for solving the "what disk does BIOS think is my boot disk" problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit. Jeff

[PATCH] adding PCI bus information to SCSI layer

Thanks everyone for your input again. I've made the changes suggested, and would appreciate this being applied to Linus' and Alan's trees. This is necessary for solving the what disk does BIOS think is my boot disk problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit. Jeff

Re: [PATCH] adding PCI bus information to SCSI layer

At 3:59 PM -0600 4/24/01, Richard Gooch wrote: The plan I have (which I hope to get started on soon, now that I'm back from travels), is to change /dev/scsi/host# from a directory into a symbolic link to a directory called: /dev/bus/pci0/slot1/function0. Thus, to access a partition via location,

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] wrote: > > [snip] > > Doug suggested looking at extending scsimon. This is a fine idea, and I've > made proposed changes available at http://domsch.com/linux/scsi/. (Doug may > want to clean this up). However, this, like my earlier changes to > /proc/scsi/scsi, doesn't

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] wrote: > > > PCI ids can be derived from bus/slot/function. > > Even better. I'll remove the extraneous fields then, and only return those. > > typedef struct scsi_pci { > unsigned char bus_number; > unsigned intdevfn; /* encoded device &

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

> PCI ids can be derived from bus/slot/function. Even better. I'll remove the extraneous fields then, and only return those. typedef struct scsi_pci { unsigned char bus_number; unsigned intdevfn; /* encoded device & function index */ } Scsi_Pci; Thanks, Matt --

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] wrote: > I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and > subsystem vendor and device IDs. PCI ids can be derived from bus/slot/function. -- Jeff Garzik | The difference between America and England is that Building 1024| the English

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

Thanks everyone for your input. Doug Gilbert said: > SANE (and probably some other applications) parses the > output of 'cat /proc/scsi/scsi' so any change to its > format may trip SANE up. How about another entry in > the /proc/scsi directory that has a more parsable format > (e.g. xml :-) ).

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

Thanks everyone for your input. Doug Gilbert said: SANE (and probably some other applications) parses the output of 'cat /proc/scsi/scsi' so any change to its format may trip SANE up. How about another entry in the /proc/scsi directory that has a more parsable format (e.g. xml :-) ). This

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] wrote: I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and subsystem vendor and device IDs. PCI ids can be derived from bus/slot/function. -- Jeff Garzik | The difference between America and England is that Building 1024| the English think

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

PCI ids can be derived from bus/slot/function. Even better. I'll remove the extraneous fields then, and only return those. typedef struct scsi_pci { unsigned char bus_number; unsigned intdevfn; /* encoded device function index */ } Scsi_Pci; Thanks, Matt --

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] wrote: PCI ids can be derived from bus/slot/function. Even better. I'll remove the extraneous fields then, and only return those. typedef struct scsi_pci { unsigned char bus_number; unsigned intdevfn; /* encoded device function index

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[EMAIL PROTECTED] wrote: [snip] Doug suggested looking at extending scsimon. This is a fine idea, and I've made proposed changes available at http://domsch.com/linux/scsi/. (Doug may want to clean this up). However, this, like my earlier changes to /proc/scsi/scsi, doesn't actually

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

Alan Cox wrote: > > > Also ISA adapters are not the only non-PCI adapters, > > there are the growing band of pseudo adapters that > > may or may not have a PCI bus at the bottom of some > > other protocol stack. > > An ioctl might be better. We already have an ioctl for querying the lun >

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

At 4:34 PM -0500 2001-04-13, Matt Domsch wrote: >What I'd like to do is add the PCI location of the SCSI controller to >the information printed in /proc/scsi/scsi, as follows: > >Attached devices: >Host: scsi0 Channel: 00 Id: 05 Lun: 00 PCI bus: 1 slot: 6 fn: 0 > Vendor: NEC Model: CD-ROM

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

At 4:34 PM -0500 2001-04-13, Matt Domsch wrote: What I'd like to do is add the PCI location of the SCSI controller to the information printed in /proc/scsi/scsi, as follows: Attached devices: Host: scsi0 Channel: 00 Id: 05 Lun: 00 PCI bus: 1 slot: 6 fn: 0 Vendor: NEC Model: CD-ROM

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

Alan Cox wrote: Also ISA adapters are not the only non-PCI adapters, there are the growing band of pseudo adapters that may or may not have a PCI bus at the bottom of some other protocol stack. An ioctl might be better. We already have an ioctl for querying the lun information for a

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

> An ioctl might be better. We already have an ioctl for > querying the lun > information for a disk. We could also return the bus > information for its > controller(s) [remember multipathing] I provide such, and a test program at http://domsch.com/linux/scsi for trying it out. Thanks, Matt

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

> Also ISA adapters are not the only non-PCI adapters, > there are the growing band of pseudo adapters that > may or may not have a PCI bus at the bottom of some > other protocol stack. An ioctl might be better. We already have an ioctl for querying the lun information for a disk. We could also

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

Matt Domsch <[EMAIL PROTECTED]> wrote: > I'm working on an IA-64 user-space application to add a Linux entry to > the IA-64 boot manager. To do so, I've got to uniquely identify a > disk by it's controller PCI address, SCSI channel, > ID, and LUN. Essentially, I need to tie /dev/sda to an EFI

[RFC][PATCH] adding PCI bus information to SCSI layer

I'm working on an IA-64 user-space application to add a Linux entry to the IA-64 boot manager. To do so, I've got to uniquely identify a disk by it's controller PCI address, SCSI channel, ID, and LUN. Essentially, I need to tie /dev/sda to an EFI device. An equivalent problem (with similar

[RFC][PATCH] adding PCI bus information to SCSI layer

I'm working on an IA-64 user-space application to add a Linux entry to the IA-64 boot manager. To do so, I've got to uniquely identify a disk by it's controller PCI address, SCSI channel, ID, and LUN. Essentially, I need to tie /dev/sda to an EFI device. An equivalent problem (with similar

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

Matt Domsch [EMAIL PROTECTED] wrote: I'm working on an IA-64 user-space application to add a Linux entry to the IA-64 boot manager. To do so, I've got to uniquely identify a disk by it's controller PCI address, SCSI channel, ID, and LUN. Essentially, I need to tie /dev/sda to an EFI device.

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

Also ISA adapters are not the only non-PCI adapters, there are the growing band of pseudo adapters that may or may not have a PCI bus at the bottom of some other protocol stack. An ioctl might be better. We already have an ioctl for querying the lun information for a disk. We could also

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

An ioctl might be better. We already have an ioctl for querying the lun information for a disk. We could also return the bus information for its controller(s) [remember multipathing] I provide such, and a test program at http://domsch.com/linux/scsi for trying it out. Thanks, Matt --