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 > >> >stuf

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"

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 line

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 cha

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 want

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 s

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. > > So

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 archi

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 /dev/

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 they

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 "compre

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) bet

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 lo

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

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 locatio

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 Gar

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 actua

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 & functi

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 think

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 :-) ). T

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 > inform

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 DR

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 r

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 de

[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 solu