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

[Kai Henningsen]

[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
> >>  >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 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 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 strange limit, but there you
> are

It's the unchanged old RFC 821 SMTP line length limit [4.5.3 SIZES, text  
line] (the consequences are just spelt out more clearly). And 821 is from  
1982, so this is certainly not new in any sense of the word.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Kai Henningsen]

[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 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 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 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 strange limit, but there you
 are

It's the unchanged old RFC 821 SMTP line length limit [4.5.3 SIZES, text  
line] (the consequences are just spelt out more clearly). And 821 is from  
1982, so this is certainly not new in any sense of the word.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 that it's neither so large a number 
that keeping track is not a concern, nor so small that it fits on a 
screen (or is reasonable to scroll).

Yes, it does appear to be a standard; I was confused because it 
hadn't propagated everywhere.

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ralf Baechle]

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 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 strange limit, but there you 
> are

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.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Steven Willoughby]

> >>
> >  > 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 strange limit, but there you 
> are
> 

Perhaps it's 998 so that with the \r\n end of line it rounds out to an
even 1000.
That limit is slightly more sensical.

Steven

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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
>>  >irregardless of good or bad design it's just plain illegal.
>>  >
>>  >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 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 strange limit, but there you 
are

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ralf Baechle]

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 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 clients do it. 
> What's the relevant RFC?

RFC 2822, 2.1.1.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ralf Baechle]

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 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 clients do it. 
 What's the relevant RFC?

RFC 2822, 2.1.1.

  Ralf
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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
  irregardless of good or bad design it's just plain illegal.
  
  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 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 strange limit, but there you 
are

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Steven Willoughby]

 
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 strange limit, but there you 
 are
 

Perhaps it's 998 so that with the \r\n end of line it rounds out to an
even 1000.
That limit is slightly more sensical.

Steven

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ralf Baechle]

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 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 strange limit, but there you 
 are

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.

  Ralf
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 that it's neither so large a number 
that keeping track is not a concern, nor so small that it fits on a 
screen (or is reasonable to scroll).

Yes, it does appear to be a standard; I was confused because it 
hadn't propagated everywhere.

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

>   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 HFS and
> NTFS... you might want to check the two very similar ideas don't
> collide.

No collisions. There are other good reasons you dont want to do forks on files
that way (you need to enumerate them but if you make them directories all hell
breaks loose).

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 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 long lines, and that an MUA
>>  has no business altering outgoing messages (one on-topic reason being
>>  that patches get screwed up by inserted newlines), but I grant that
>>  there are broken clients out there that can't or won't or don't wrap
>>  at display time.
>
>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 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 clients do it. 
What's the relevant RFC?

>MfG Kai


-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Kai Henningsen]

[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.
>
> Sorry for the inconvenience. There are a lot of reasons why I believe
> it's properly a display function to wrap long lines, and that an MUA
> has no business altering outgoing messages (one on-topic reason being
> that patches get screwed up by inserted newlines), but I grant that
> there are broken clients out there that can't or won't or don't wrap
> at display time.

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 support wrapping with plain text, investigate  
format=flowed.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Kai Henningsen]

[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 the inconvenience. There are a lot of reasons why I believe
 it's properly a display function to wrap long lines, and that an MUA
 has no business altering outgoing messages (one on-topic reason being
 that patches get screwed up by inserted newlines), but I grant that
 there are broken clients out there that can't or won't or don't wrap
 at display time.

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 support wrapping with plain text, investigate  
format=flowed.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 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 long lines, and that an MUA
  has no business altering outgoing messages (one on-topic reason being
  that patches get screwed up by inserted newlines), but I grant that
  there are broken clients out there that can't or won't or don't wrap
  at display time.

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 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 clients do it. 
What's the relevant RFC?

MfG Kai


-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

   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 HFS and
 NTFS... you might want to check the two very similar ideas don't
 collide.

No collisions. There are other good reasons you dont want to do forks on files
that way (you need to enumerate them but if you make them directories all hell
breaks loose).

Alan

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

> 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 the device node, not the options.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Oeser]

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/ttyF00 c 100 100
> 
>   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

Ouch! 

How is that supposed to work with the dcache?

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.

I don't know how people call this, if they call sth. like DevFS
"crappy", but I would be very surprised, if they call it "clean".

Just think of: 

test -r /dev/ttyF00/speed=9600,clocal && cat /dev/ttyF00/speed=9600,clocal

Or the equivalent in C in most of the programs, which read sth.

POSIX might not forbid this, because common sense already does ;-)

Regards

Ingo Oeser

[1] entry := directory | file
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Oeser]

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/ttyF00 c 100 100
 
   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

Ouch! 

How is that supposed to work with the dcache?

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.

I don't know how people call this, if they call sth. like DevFS
crappy, but I would be very surprised, if they call it clean.

Just think of: 

test -r /dev/ttyF00/speed=9600,clocal  cat /dev/ttyF00/speed=9600,clocal

Or the equivalent in C in most of the programs, which read sth.

POSIX might not forbid this, because common sense already does ;-)

Regards

Ingo Oeser

[1] entry := directory | file
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
  been there and had much fun   
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

 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 the device node, not the options.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

> 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 bios pnp device in 2.4-ac

> However, it's my understanding that Linus isn't trying to push
> existing drivers, which work well with devfs, into implementing their
> own FS. He just wants the option left open for new drivers where a
> driver-specific FS makes more sense.

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/ttyF00 c 100 100

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Richard Gooch]

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 mounted independently) better into /dev/bus.

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").

So, if the bus management code is maintaining some kind of unified
tree, it might not make sense to have a /dev/bus/pci and
/dev/bus/sbus.

> And even implement the thing as a mount point later, if we go the way
> Al Viro suggested and have independent "device filesystems"
> for the subsystems themselves.

As I understand it, Al want to turn every driver into a filesystem,
instead of using an existing FS (devfs). I can't see the point. There
certainly haven't been any technical benefits put forward for this
idea.

I spoke to Linus about this, and he wants to leave the option open for
some drivers to implement their own FS rather than calling into devfs.
He cited iSCSI as a case where this might be useful (since you need to
do something different for readdir() and lookup()). I'll be
experimenting with iSCSI myself, and I'll try out a modification to
devfs which allows a driver to register lookup() and readdir() methods
when calling devfs_mk_dir(). If this can be done sanely, then it would
provide an easier interface than using the VFS to implement a new FS.
So this particular issue remains open.

However, it's my understanding that Linus isn't trying to push
existing drivers, which work well with devfs, into implementing their
own FS. He just wants the option left open for new drivers where a
driver-specific FS makes more sense.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 wants them to be
>obvious at first glance. My original devfs patch (before it went into
>the kernel) had compressed names, and he made me change them (there
>were other changes as well). I know it's a bit much to type in, but
>he's probably right. If people need it, I can add compressed names to
>devfsd, just like I did to preserve the names in the original devfs
>patch.

OK. Not a big deal, really.

/dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3

becomes

/device/bus/peripheralcomponentinterconnect0/device1/function0/bus0/target1/logicalunitnumber2/partition3
 
:-)

>  > A related idea would be the ability to translate from a logical PCI
>>  slot number, as above, and a physically meaningful description that
>>  the user could use to identify an actual slot. Unfortunately the
>>  proper place for such a translation function is in the
>>  (hardware-specific) BIOS.
>
>Nope. It's cleaner to do this in a vendor-specific "fixup" layer.

I agree, actually. If there *were* BIOS support for such geographic 
information (and while there should be there isn't), the 
vendor-specific fixup could take advantage of it. The point about 
BIOS is that it's connected to the specific hardware, and is the 
appropriate (ultimate) repository for that kind of information. In a 
related vein (for example) Sun's OBP (BIOS-equivalent) provides a 
lookup function that converts a physical memory address (generally 
after an ECC error) to a physical DIMM U-number, for human reporting 
purposes. But it's a moot point, so never mind

>Alan
>asked me a similar question privately, so I've included my reponse to
>his email (quoting bits of his email for context) below. In his reply,
>Alan said "it makes sense". I take that as a good omen.
>=
>>  How do you intend to handle pci busses that are below other busses - eg gsc
>>  /dev/bus/gsc/bus/pci0/ .. ?
>  > Im just thinking it gets very cumbersome.

It *does* address my concern about multiple PCI subsystems.

>It could. And if you play with the upcoming SGI IA-64 boxes, where
>they have a deep /dev/hw, it would appear even more so. However, I
>came up with a scheme while I was visiting them after the workshop,
>which I believe will handle an arbitrarily complex vendor tree. I'm
>actually quite proud of this idea :-)
>
>The basic idea is that /dev/bus contains a *logical* enumeration of
>all busses in the system. This contains the generic Linux view of
>busses. We already have this enumeration within struct pci_dev and
>friends.
>
>Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
>into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or
>similar, I forget just how deep SGI's tree went).
>
>This scheme is really just an extension of the approach Linus took in
>the Great Name Change he forced upon me a year and a half ago. Back
>then, he wanted /dev/discs to answer the question "what discs do I
>have", and "/dev/scsi" to answer "what SCSI devices do I have, and
>what's the layout". So now, I'm adding "/dev/bus" for "what logical
>busses do I have" and "/dev/hw" for "what is the exact hardware
>topology".
>
>Where we have "generic" hardware (i.e. a vendor doesn't provide their
>own PCI fixups), and there is a need to show the bus topology, we can
>write generic fixups that parse the struct pci_dev and friends. For
>example, most x86 machines would fall in this "generic" category.

Reasonable, especially if a fixup map could be created by a user in 
the absence of a vendor-supplied map. (When/where does /dev/hw/ get 
created?)

On a related note, how does the current pci_dev tree deal with 
multiple PCI subsystems? For example, in pci.c we have

struct pci_dev *
pci_find_slot(unsigned int bus, unsigned int devfn)
{
struct pci_dev *dev;

pci_for_each_dev(dev) {
if (dev->bus->number == bus && dev->devfn == devfn)
return dev;
}
return NULL;
}

...which appears on the face of it (assuming a single tree) to ignore 
the possibility of bus-number aliasing across PCI subsystems.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Oeser]

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) better into /dev/bus.

And even implement the thing as a mount point later, if we go the way
Al Viro suggested and have independent "device filesystems"
for the subsystems themselves.

Just an idea...

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Oeser]

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) better into /dev/bus.

And even implement the thing as a mount point later, if we go the way
Al Viro suggested and have independent device filesystems
for the subsystems themselves.

Just an idea...

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
  been there and had much fun   
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 wants them to be
obvious at first glance. My original devfs patch (before it went into
the kernel) had compressed names, and he made me change them (there
were other changes as well). I know it's a bit much to type in, but
he's probably right. If people need it, I can add compressed names to
devfsd, just like I did to preserve the names in the original devfs
patch.

OK. Not a big deal, really.

/dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3

becomes

/device/bus/peripheralcomponentinterconnect0/device1/function0/bus0/target1/logicalunitnumber2/partition3
 
:-)

   A related idea would be the ability to translate from a logical PCI
  slot number, as above, and a physically meaningful description that
  the user could use to identify an actual slot. Unfortunately the
  proper place for such a translation function is in the
  (hardware-specific) BIOS.

Nope. It's cleaner to do this in a vendor-specific fixup layer.

I agree, actually. If there *were* BIOS support for such geographic 
information (and while there should be there isn't), the 
vendor-specific fixup could take advantage of it. The point about 
BIOS is that it's connected to the specific hardware, and is the 
appropriate (ultimate) repository for that kind of information. In a 
related vein (for example) Sun's OBP (BIOS-equivalent) provides a 
lookup function that converts a physical memory address (generally 
after an ECC error) to a physical DIMM U-number, for human reporting 
purposes. But it's a moot point, so never mind

Alan
asked me a similar question privately, so I've included my reponse to
his email (quoting bits of his email for context) below. In his reply,
Alan said it makes sense. I take that as a good omen.
=
  How do you intend to handle pci busses that are below other busses - eg gsc
  /dev/bus/gsc/bus/pci0/ .. ?
   Im just thinking it gets very cumbersome.

It *does* address my concern about multiple PCI subsystems.

It could. And if you play with the upcoming SGI IA-64 boxes, where
they have a deep /dev/hw, it would appear even more so. However, I
came up with a scheme while I was visiting them after the workshop,
which I believe will handle an arbitrarily complex vendor tree. I'm
actually quite proud of this idea :-)

The basic idea is that /dev/bus contains a *logical* enumeration of
all busses in the system. This contains the generic Linux view of
busses. We already have this enumeration within struct pci_dev and
friends.

Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or
similar, I forget just how deep SGI's tree went).

This scheme is really just an extension of the approach Linus took in
the Great Name Change he forced upon me a year and a half ago. Back
then, he wanted /dev/discs to answer the question what discs do I
have, and /dev/scsi to answer what SCSI devices do I have, and
what's the layout. So now, I'm adding /dev/bus for what logical
busses do I have and /dev/hw for what is the exact hardware
topology.

Where we have generic hardware (i.e. a vendor doesn't provide their
own PCI fixups), and there is a need to show the bus topology, we can
write generic fixups that parse the struct pci_dev and friends. For
example, most x86 machines would fall in this generic category.

Reasonable, especially if a fixup map could be created by a user in 
the absence of a vendor-supplied map. (When/where does /dev/hw/ get 
created?)

On a related note, how does the current pci_dev tree deal with 
multiple PCI subsystems? For example, in pci.c we have

struct pci_dev *
pci_find_slot(unsigned int bus, unsigned int devfn)
{
struct pci_dev *dev;

pci_for_each_dev(dev) {
if (dev-bus-number == bus  dev-devfn == devfn)
return dev;
}
return NULL;
}

...which appears on the face of it (assuming a single tree) to ignore 
the possibility of bus-number aliasing across PCI subsystems.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Richard Gooch]

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 mounted independently) better into /dev/bus.

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

So, if the bus management code is maintaining some kind of unified
tree, it might not make sense to have a /dev/bus/pci and
/dev/bus/sbus.

 And even implement the thing as a mount point later, if we go the way
 Al Viro suggested and have independent device filesystems
 for the subsystems themselves.

As I understand it, Al want to turn every driver into a filesystem,
instead of using an existing FS (devfs). I can't see the point. There
certainly haven't been any technical benefits put forward for this
idea.

I spoke to Linus about this, and he wants to leave the option open for
some drivers to implement their own FS rather than calling into devfs.
He cited iSCSI as a case where this might be useful (since you need to
do something different for readdir() and lookup()). I'll be
experimenting with iSCSI myself, and I'll try out a modification to
devfs which allows a driver to register lookup() and readdir() methods
when calling devfs_mk_dir(). If this can be done sanely, then it would
provide an easier interface than using the VFS to implement a new FS.
So this particular issue remains open.

However, it's my understanding that Linus isn't trying to push
existing drivers, which work well with devfs, into implementing their
own FS. He just wants the option left open for new drivers where a
driver-specific FS makes more sense.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

 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 bios pnp device in 2.4-ac

 However, it's my understanding that Linus isn't trying to push
 existing drivers, which work well with devfs, into implementing their
 own FS. He just wants the option left open for new drivers where a
 driver-specific FS makes more sense.

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/ttyF00 c 100 100

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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Richard Gooch]

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 
> location of devices, or at least a uniform parsable format. (A 
> potential shortcoming of Jeff's scheme, perhaps, is that it needs to 
> identify the slot_name as a PCI slot_name, though I could be missing 
> something there.)
> 
> 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 wants them to be
obvious at first glance. My original devfs patch (before it went into
the kernel) had compressed names, and he made me change them (there
were other changes as well). I know it's a bit much to type in, but
he's probably right. If people need it, I can add compressed names to
devfsd, just like I did to preserve the names in the original devfs
patch.

> A related idea would be the ability to translate from a logical PCI 
> slot number, as above, and a physically meaningful description that 
> the user could use to identify an actual slot. Unfortunately the 
> proper place for such a translation function is in the 
> (hardware-specific) BIOS.

Nope. It's cleaner to do this in a vendor-specific "fixup" layer. Alan
asked me a similar question privately, so I've included my reponse to
his email (quoting bits of his email for context) below. In his reply,
Alan said "it makes sense". I take that as a good omen.
=
> How do you intend to handle pci busses that are below other busses - eg gsc
> /dev/bus/gsc/bus/pci0/ .. ?
> Im just thinking it gets very cumbersome.

It could. And if you play with the upcoming SGI IA-64 boxes, where
they have a deep /dev/hw, it would appear even more so. However, I
came up with a scheme while I was visiting them after the workshop,
which I believe will handle an arbitrarily complex vendor tree. I'm
actually quite proud of this idea :-)

The basic idea is that /dev/bus contains a *logical* enumeration of
all busses in the system. This contains the generic Linux view of
busses. We already have this enumeration within struct pci_dev and
friends.

Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or
similar, I forget just how deep SGI's tree went).

This scheme is really just an extension of the approach Linus took in
the Great Name Change he forced upon me a year and a half ago. Back
then, he wanted /dev/discs to answer the question "what discs do I
have", and "/dev/scsi" to answer "what SCSI devices do I have, and
what's the layout". So now, I'm adding "/dev/bus" for "what logical
busses do I have" and "/dev/hw" for "what is the exact hardware
topology".

Where we have "generic" hardware (i.e. a vendor doesn't provide their
own PCI fixups), and there is a need to show the bus topology, we can
write generic fixups that parse the struct pci_dev and friends. For
example, most x86 machines would fall in this "generic" category.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Richard Gooch]

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 
 location of devices, or at least a uniform parsable format. (A 
 potential shortcoming of Jeff's scheme, perhaps, is that it needs to 
 identify the slot_name as a PCI slot_name, though I could be missing 
 something there.)
 
 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 wants them to be
obvious at first glance. My original devfs patch (before it went into
the kernel) had compressed names, and he made me change them (there
were other changes as well). I know it's a bit much to type in, but
he's probably right. If people need it, I can add compressed names to
devfsd, just like I did to preserve the names in the original devfs
patch.

 A related idea would be the ability to translate from a logical PCI 
 slot number, as above, and a physically meaningful description that 
 the user could use to identify an actual slot. Unfortunately the 
 proper place for such a translation function is in the 
 (hardware-specific) BIOS.

Nope. It's cleaner to do this in a vendor-specific fixup layer. Alan
asked me a similar question privately, so I've included my reponse to
his email (quoting bits of his email for context) below. In his reply,
Alan said it makes sense. I take that as a good omen.
=
 How do you intend to handle pci busses that are below other busses - eg gsc
 /dev/bus/gsc/bus/pci0/ .. ?
 Im just thinking it gets very cumbersome.

It could. And if you play with the upcoming SGI IA-64 boxes, where
they have a deep /dev/hw, it would appear even more so. However, I
came up with a scheme while I was visiting them after the workshop,
which I believe will handle an arbitrarily complex vendor tree. I'm
actually quite proud of this idea :-)

The basic idea is that /dev/bus contains a *logical* enumeration of
all busses in the system. This contains the generic Linux view of
busses. We already have this enumeration within struct pci_dev and
friends.

Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or
similar, I forget just how deep SGI's tree went).

This scheme is really just an extension of the approach Linus took in
the Great Name Change he forced upon me a year and a half ago. Back
then, he wanted /dev/discs to answer the question what discs do I
have, and /dev/scsi to answer what SCSI devices do I have, and
what's the layout. So now, I'm adding /dev/bus for what logical
busses do I have and /dev/hw for what is the exact hardware
topology.

Where we have generic hardware (i.e. a vendor doesn't provide their
own PCI fixups), and there is a need to show the bus topology, we can
write generic fixups that parse the struct pci_dev and friends. For
example, most x86 machines would fall in this generic category.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 long lines, and that an MUA 
has no business altering outgoing messages (one on-topic reason being 
that patches get screwed up by inserted newlines), but I grant that 
there are broken clients out there that can't or won't or don't wrap 
at display time.

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 
location of devices, or at least a uniform parsable format. (A 
potential shortcoming of Jeff's scheme, perhaps, is that it needs to 
identify the slot_name as a PCI slot_name, though I could be missing 
something there.)

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

Are there systems with more than one PCI bus numbering domain? I 
don't see why not, in principle (not an issue for SCSI, which doesn't 
have bus numbering). So perhaps:

/dev/bus/pci0:b0:d1:f0/scsi0:t1:l2:p3

which distinguishes between PCI domains and PCI bus numbers.

At 10:31 PM -0600 2001-04-26, Richard Gooch wrote:
>Sure. I haven't made a decision on the names yet. I was just sketching
>out the idea.

It's a good idea. Just feedback on the initial sketch.

A related idea would be the ability to translate from a logical PCI 
slot number, as above, and a physically meaningful description that 
the user could use to identify an actual slot. Unfortunately the 
proper place for such a translation function is in the 
(hardware-specific) BIOS.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Richard Gooch]

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 access a partition via location, one would use the path:
> >/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.
> 
> A minor PCI terminology point: PCI buses are subdivided into
> devices, not (necessarily) slots. So, for example, a multiple-device
> PCI card (say, two SCSI controllers) might have a PCI bridge
> creating a new bus, and two devices (not slots) on that bus. (It
> could alternatively be implemented as a single device with two
> functions, given a dual-interface chip, but not necessarily.)
>
> So a better name would be
> /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the liberty of
> abbreviating some of the other names).

Sure. I haven't made a decision on the names yet. I was just sketching
out the idea.

> How, if at all, would RAID devices, using more than one physical
> device, or SCSI bus, or PCI card, fit into this naming scheme?

Same as it does now. There's the underlying devices, and then the meta
devices, which are under /dev/md.

BTW: please fix your mailer to do linewrap at 72 characters. Your
lines are hundreds of characters long, and that's hard to read.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Richard Gooch]

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 access a partition via location, one would use the path:
 /dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.
 
 A minor PCI terminology point: PCI buses are subdivided into
 devices, not (necessarily) slots. So, for example, a multiple-device
 PCI card (say, two SCSI controllers) might have a PCI bridge
 creating a new bus, and two devices (not slots) on that bus. (It
 could alternatively be implemented as a single device with two
 functions, given a dual-interface chip, but not necessarily.)

 So a better name would be
 /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the liberty of
 abbreviating some of the other names).

Sure. I haven't made a decision on the names yet. I was just sketching
out the idea.

 How, if at all, would RAID devices, using more than one physical
 device, or SCSI bus, or PCI card, fit into this naming scheme?

Same as it does now. There's the underlying devices, and then the meta
devices, which are under /dev/md.

BTW: please fix your mailer to do linewrap at 72 characters. Your
lines are hundreds of characters long, and that's hard to read.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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, one would use the path:
>/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.

A minor PCI terminology point: PCI buses are subdivided into devices, not 
(necessarily) slots. So, for example, a multiple-device PCI card (say, two SCSI 
controllers) might have a PCI bridge creating a new bus, and two devices (not slots) 
on that bus. (It could alternatively be implemented as a single device with two 
functions,  given a dual-interface chip, but not necessarily.)

So a better name would be /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the 
liberty of abbreviating some of the other names).

How, if at all, would RAID devices, using more than one physical device, or SCSI bus, 
or PCI card, fit into this naming scheme?


-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Richard Gooch]

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 when BIOSs permit.
> 
> Jeff Garzik recommended the IOCTL return pci_dev::slot_name, so now it does,
> and this simplifies the ioctl greatly.
> Doug Gilbert recommended wrapping things in #ifdef's, so I created a new
> CONFIG_SCSI_PCI_INFO define.

As I said to Matt privately, I think adding this kind of ioctl is
ugly. We have enough ioctl's as it is. All Matt is trying to do is to
access drives via location, so exposing location-based device nodes
via devfs is IMNSHO cleaner.

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, one would use the path:
/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] adding PCI bus information to SCSI layer

[Matt_Domsch]

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 Garzik recommended the IOCTL return pci_dev::slot_name, so now it does,
and this simplifies the ioctl greatly.
Doug Gilbert recommended wrapping things in #ifdef's, so I created a new
CONFIG_SCSI_PCI_INFO define.

Patches against 2.4.4-pre6 are available at http://domsch.com/linux/scsi/.
linux-2.4.4-pre6-scsi-pci-info-010424.patch - Adds the IOCTL and
CONFIG_SCSI_PCI_INFO, and touches a bunch of SCSI drivers.
scsimon_243_1_pci-010424.patch - Changes scsimon Makefile and sm_test.c to
support this.
scsimon_243_1_pci_driver.patch - Changes scsimon.[ch] to support this.

When this goes in, I request the assistance of the SCSI driver maintainers.
I've changed quite a few drivers, but couldn't easily see how to change a
few others.  I am bcc'ing the maintainers of drivers I changed or need help
from.

Drivers that I changed:

3w-.c   
AM53C974.c  
advansys.c  
aic7xxx_old.c   
atp870u.c   
cpqfcTSinit.c   
dmx3191d.c
fdomain.c   
gdth.c  
ips.c   
ncr53c8xx.c 
qla1280.c   
qlogicfc.c  
qlogicisp.c 
sym53c8xx.c 
tmscsim.c   
megaraid.c  
53c7,8xx.c  
pci2000.c   
pci2220i.c  


Non-trivial drivers that I didn't change, but request their
maintainers do so:

BusLogic.c  
aic7xxx.c   
eata.c  
eata_dma.c  
eata_pio.c  
ini9100u.c  
inia100.c   


Drivers I didn't need to change (they're not PCI devices, best as I can
tell):
NCR53C9x.c
NCR53c406a.c
aha152x.c
aha1542.c
aha1740.c
esp.c
fd_mcs.c
ibmmca.c
ide-scsi.c
imm.c
in2000.c
mac53c94.c
mesh.c
ppa.c
qlogicfas.c
qlogicpti.c
sgiwd93.c
sim710.c
sym53c416.c
u14-34f.c
ultrastor.c
53c7xx.c
a2091.c
a3000.c
atari_scsi.c
dtc.c
fcal.c
g_NCR5380.c
gvp11.c
mac_scsi.c
mvme147.c
pas16.c
pluto.c
psi240i.c
seagate.c
sun3_scsi.c
t128.c
wd7000.c


Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] adding PCI bus information to SCSI layer

[Matt_Domsch]

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 Garzik recommended the IOCTL return pci_dev::slot_name, so now it does,
and this simplifies the ioctl greatly.
Doug Gilbert recommended wrapping things in #ifdef's, so I created a new
CONFIG_SCSI_PCI_INFO define.

Patches against 2.4.4-pre6 are available at http://domsch.com/linux/scsi/.
linux-2.4.4-pre6-scsi-pci-info-010424.patch - Adds the IOCTL and
CONFIG_SCSI_PCI_INFO, and touches a bunch of SCSI drivers.
scsimon_243_1_pci-010424.patch - Changes scsimon Makefile and sm_test.c to
support this.
scsimon_243_1_pci_driver.patch - Changes scsimon.[ch] to support this.

When this goes in, I request the assistance of the SCSI driver maintainers.
I've changed quite a few drivers, but couldn't easily see how to change a
few others.  I am bcc'ing the maintainers of drivers I changed or need help
from.

Drivers that I changed:

3w-.c   
AM53C974.c  
advansys.c  
aic7xxx_old.c   
atp870u.c   
cpqfcTSinit.c   
dmx3191d.c
fdomain.c   
gdth.c  
ips.c   
ncr53c8xx.c 
qla1280.c   
qlogicfc.c  
qlogicisp.c 
sym53c8xx.c 
tmscsim.c   
megaraid.c  
53c7,8xx.c  
pci2000.c   
pci2220i.c  


Non-trivial drivers that I didn't change, but request their
maintainers do so:

BusLogic.c  
aic7xxx.c   
eata.c  
eata_dma.c  
eata_pio.c  
ini9100u.c  
inia100.c   


Drivers I didn't need to change (they're not PCI devices, best as I can
tell):
NCR53C9x.c
NCR53c406a.c
aha152x.c
aha1542.c
aha1740.c
esp.c
fd_mcs.c
ibmmca.c
ide-scsi.c
imm.c
in2000.c
mac53c94.c
mesh.c
ppa.c
qlogicfas.c
qlogicpti.c
sgiwd93.c
sim710.c
sym53c416.c
u14-34f.c
ultrastor.c
53c7xx.c
a2091.c
a3000.c
atari_scsi.c
dtc.c
fcal.c
g_NCR5380.c
gvp11.c
mac_scsi.c
mvme147.c
pas16.c
pluto.c
psi240i.c
seagate.c
sun3_scsi.c
t128.c
wd7000.c


Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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, one would use the path:
/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.

A minor PCI terminology point: PCI buses are subdivided into devices, not 
(necessarily) slots. So, for example, a multiple-device PCI card (say, two SCSI 
controllers) might have a PCI bridge creating a new bus, and two devices (not slots) 
on that bus. (It could alternatively be implemented as a single device with two 
functions,  given a dual-interface chip, but not necessarily.)

So a better name would be /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the 
liberty of abbreviating some of the other names).

How, if at all, would RAID devices, using more than one physical device, or SCSI bus, 
or PCI card, fit into this naming scheme?


-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Douglas Gilbert]

[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 show the relationship between /dev/sda and
> a particular PCI controller and SCSI channel,bus,lun tuple.

Changes look ok. One suggestion: if a #define SCSI_PCI_INFO
(or some such) is defined in driver/scsi/scsi.h as part of
the patch then code like Matt is suggesting can be safely 
added, protected by "#ifdef SCSI_PCI_INFO ... #endif" blocks. 
I have used this technique in sg to support the scsi 
"reset+reservation" patch which still hasn't made it into 
the mid level (but is available in many distros).

The scsimon driver is just a window through to the information
held in the mid level structures. The information printed by
'cat /proc/scsi/scsi' also comes from the mid level. The scsi 
minor device numbers (e.g. /dev/sda) are allocated by each upper 
level driver  (e.g. sd_attach() in the case of sd) and are held 
in upper level driver data structures. Hence they are not 
visible to the mid-level or to other upper level drivers.

As an example of the latter point, using st and sg on the same 
tape device at the same time will most likely confuse st 
(since it maintains a state machine). However there is no 
simple way for the sg or st drivers to detect (or supply
information flagging) this conflict.

Doug Gilbert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jeff Garzik]

[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
> */
> } Scsi_Pci;

Why not pci_dev::slot_name?  Presumeably the only reason you need this
is to export it to userspace...  We already have the ASCII text there,
please consider using that :)

-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt_Domsch]

> 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

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jeff Garzik]

[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 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt_Domsch]

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 makes a lot of sense, but I don't want to fan the war over what kind of
information should be presented in /proc. :-)  Perhaps this can wait for
scsimon changes.

Doug Gilbert said: 
> 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.

Alan said:
> 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]

If I understand multipathing properly, a /dev/mdX device is composed of
several block devices, and there are IOCTLs available to list the individual
devices that compose a block device.  Each multipath component shows up as
both /dev/sda and /dev/sdb, but you mount /dev/md0 for your I/Os.  BIOSs
don't know about multipath devices, they just see the same disk twice and
don't know it's really only one disk.  Hopefully BIOS only reads the boot
sector and jumps, so this is fine.

I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and
subsystem vendor and device IDs.  Equivalent /dev/hdX information is
available in /proc/ide/ide0, but not as an IOCTL.  It could then be a
user-space problem to decompose a mdX into component sdX or hdX devices, and
query them appropriately.

I'm still not sure if/how to handle:
1) non-PCI-bus devices

Here I'm going to need some help.  My original design was based on the
information presented by EDD 3.0 Rev 5a (www.t13.org), which only presents
x86 int13-type devices, and shows them to be either ISA or PCI-based, with
the goal of telling the OS which device BIOS thinks is the boot device.
Booting off, say, a parallel-port ZIP drive isn't really handled in EDD.  


2) Devices like i2o scsi disks
The i2o controller can be on any bus type (though I expect most are
PCI).  The i2o_controller struct has an i2o_hrt member, which does have bus
information, but the PCI struct doesn't include subsystem vendor and device
fields yet.  We'd need to add an IOCTL to retrieve this information,
possibly one at a generic i2o level.   The EDD 3.0 spec shows that a PCI i2o
device returns us a 64-bit Identity Tag, which I'm guessing is the same as a
32-bit target device ID and possibly the TID of the controller too.

3) other block devices (non-SCSI, i2o, or IDE).  I haven't investigated
these.


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 show the relationship between /dev/sda and
a particular PCI controller and SCSI channel,bus,lun tuple.


I'd like to see the the PCI device information added to the Scsi_Host
structure, the ioctl, and the various PCI SCSI driver changes I mentioned
last week.  I've removed the changes to /proc/scsi/scsi and rebuilt it
against 2.4.4-pre6, available at
http://domsch.com/linux/scsi/linux-2.4.4-pre6-scsi-pci-info-noproc.patch

If/when this goes in, I'll also request the assistance of all of the SCSI
driver maintainers.  I've changed quite a few drivers, but couldn't easily
see how to change a few others.

Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt_Domsch]

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 makes a lot of sense, but I don't want to fan the war over what kind of
information should be presented in /proc. :-)  Perhaps this can wait for
scsimon changes.

Doug Gilbert said: 
 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.

Alan said:
 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]

If I understand multipathing properly, a /dev/mdX device is composed of
several block devices, and there are IOCTLs available to list the individual
devices that compose a block device.  Each multipath component shows up as
both /dev/sda and /dev/sdb, but you mount /dev/md0 for your I/Os.  BIOSs
don't know about multipath devices, they just see the same disk twice and
don't know it's really only one disk.  Hopefully BIOS only reads the boot
sector and jumps, so this is fine.

I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and
subsystem vendor and device IDs.  Equivalent /dev/hdX information is
available in /proc/ide/ide0, but not as an IOCTL.  It could then be a
user-space problem to decompose a mdX into component sdX or hdX devices, and
query them appropriately.

I'm still not sure if/how to handle:
1) non-PCI-bus devices

Here I'm going to need some help.  My original design was based on the
information presented by EDD 3.0 Rev 5a (www.t13.org), which only presents
x86 int13-type devices, and shows them to be either ISA or PCI-based, with
the goal of telling the OS which device BIOS thinks is the boot device.
Booting off, say, a parallel-port ZIP drive isn't really handled in EDD.  


2) Devices like i2o scsi disks
The i2o controller can be on any bus type (though I expect most are
PCI).  The i2o_controller struct has an i2o_hrt member, which does have bus
information, but the PCI struct doesn't include subsystem vendor and device
fields yet.  We'd need to add an IOCTL to retrieve this information,
possibly one at a generic i2o level.   The EDD 3.0 spec shows that a PCI i2o
device returns us a 64-bit Identity Tag, which I'm guessing is the same as a
32-bit target device ID and possibly the TID of the controller too.

3) other block devices (non-SCSI, i2o, or IDE).  I haven't investigated
these.


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 show the relationship between /dev/sda and
a particular PCI controller and SCSI channel,bus,lun tuple.


I'd like to see the the PCI device information added to the Scsi_Host
structure, the ioctl, and the various PCI SCSI driver changes I mentioned
last week.  I've removed the changes to /proc/scsi/scsi and rebuilt it
against 2.4.4-pre6, available at
http://domsch.com/linux/scsi/linux-2.4.4-pre6-scsi-pci-info-noproc.patch

If/when this goes in, I'll also request the assistance of all of the SCSI
driver maintainers.  I've changed quite a few drivers, but couldn't easily
see how to change a few others.

Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jeff Garzik]

[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 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt_Domsch]

 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

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jeff Garzik]

[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
 */
 } Scsi_Pci;

Why not pci_dev::slot_name?  Presumeably the only reason you need this
is to export it to userspace...  We already have the ASCII text there,
please consider using that :)

-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Douglas Gilbert]

[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 show the relationship between /dev/sda and
 a particular PCI controller and SCSI channel,bus,lun tuple.

Changes look ok. One suggestion: if a #define SCSI_PCI_INFO
(or some such) is defined in driver/scsi/scsi.h as part of
the patch then code like Matt is suggesting can be safely 
added, protected by #ifdef SCSI_PCI_INFO ... #endif blocks. 
I have used this technique in sg to support the scsi 
reset+reservation patch which still hasn't made it into 
the mid level (but is available in many distros).

The scsimon driver is just a window through to the information
held in the mid level structures. The information printed by
'cat /proc/scsi/scsi' also comes from the mid level. The scsi 
minor device numbers (e.g. /dev/sda) are allocated by each upper 
level driver  (e.g. sd_attach() in the case of sd) and are held 
in upper level driver data structures. Hence they are not 
visible to the mid-level or to other upper level drivers.

As an example of the latter point, using st and sg on the same 
tape device at the same time will most likely confuse st 
(since it maintains a state machine). However there is no 
simple way for the sg or st drivers to detect (or supply
information flagging) this conflict.

Doug Gilbert

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Douglas Gilbert]

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 disk. We could also return the bus information for its
> controller(s) [remember multipathing]

Both 'cat /proc/scsi/scsi' and ioctls used on
fds belonging to the existing upper level drivers
(e.g. sd and sr) have a problem as far as getting
HBA environment information: there needs to be at
least one SCSI device (target) connected to the
HBA. With no SCSI devices connected, there is no 
fd to do an ioctl on. [The same problem arises
if a device is there but marked offline, has an
exclusive lock on it, ...]

Perhaps Matt could look at the approach I have taken
with the scsimon experimental upper level driver.
Scsimon was originally designed to get scsi based
information to the /sbin/hotplug mechanism. It also
supplies ioctls to probe HBAs as well as SCSI devices.
More information about it can be found at:
  http://www.torque.net/scsi/scsimon.html

It should not be difficult to add HBA PCI bus information
to scsimon (after the Scsi_Host structure is expanded to
hold that information).

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 DRIVE:466 Rev: 1.06
>  Type:   CD-ROM   ANSI SCSI revision: 02
>Host: scsi1 Channel: 00 Id: 00 Lun: 00 PCI bus: 0 slot: 2 fn: 1
>  Vendor: DELL Model: PERCRAID RAID5   Rev: 0001
>  Type:   Direct-AccessANSI SCSI revision: 02
>Host: scsi1 Channel: 00 Id: 01 Lun: 00 PCI bus: 0 slot: 2 fn: 1
>  Vendor: DELL Model: PERCRAID Stripe  Rev: 0001
>  Type:   Direct-AccessANSI SCSI revision: 02

Jeff Garzik proposed a scheme for ethtool that addresses somewhat similar needs for 
network interfaces. It's nice and general, and in particular works for non-PCI 
interfaces. Why not something like that for SCSI?

At 7:54 AM -0500 2001-03-21, Jeff Garzik wrote:
>In various scenarios where userland needs to interact with hardware,
>userland often needs to know exactly what driver (and driver version) is
>currently running on a given interface.  Hotplugging and other
>applications could -really- use the ability to find out bus information
>for a given interface.  Firmware
>
>So I propose the attached addition to the ethtool interface.  It adds a
>new structure with several ASCII text fields, which are filled in at the
>driver's discretion.  Userland then interprets these fields for their
>own evil designs.
>
>Currently (AFAIK) for all kernel interfaces, userland has no reliable
>way to associate a hardware device with a kernel interface, or a driver
>with a kernel interface[1].  Since we have no generic register_driver()
>interface, solving this problem means implementing a domain-specific
>solution like I have done here...
>
>--
>Jeff Garzik   | May you have warm words on a cold evening,
>Building 1024 | a full mooon on a dark night,
>MandrakeSoft  | and a smooth road all the way to your door.
>Index: include/linux/ethtool.h
>===
>RCS file: /cvsroot/gkernel/linux_2_4/include/linux/Attic/ethtool.h,v
>retrieving revision 1.1.1.2
>diff -u -r1.1.1.2 ethtool.h
>--- include/linux/ethtool.h2000/11/14 22:01:49 1.1.1.2
>+++ include/linux/ethtool.h2001/03/21 12:42:15
>@@ -24,10 +24,21 @@
>   u32 reserved[4];
> };
> 
>+/* these strings are set to whatever the driver author decides... */
>+struct ethtool_drvinfo {
>+  chardriver[32]; /* driver short name, "tulip", "eepro100" */
>+  charversion[32];/* driver version string */
>+  charfw_version[32]; /* firmware version string, if applicable */
>+  charbus_info[32];   /* Bus info for this interface.  For PCI
>+   * devices, use pci_dev->slot_name. */
>+  charreserved1[32];
>+  charreserved2[32];
>+};
> 
> /* CMDs currently supported */
>-#define ETHTOOL_GSET  0x0001 /* Get settings, non-privileged. */
>+#define ETHTOOL_GSET  0x0001 /* Get settings. */
> #define ETHTOOL_SSET  0x0002 /* Set settings, privileged. */
>+#define ETHTOOL_GDRVINFO  0x0003 /* Get driver info. */
> 
> /* compatibility with older code */
> #define SPARC_ETH_GSETETHTOOL_GSET

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Lundell]

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 DRIVE:466 Rev: 1.06
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00 PCI bus: 0 slot: 2 fn: 1
  Vendor: DELL Model: PERCRAID RAID5   Rev: 0001
  Type:   Direct-AccessANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 00 PCI bus: 0 slot: 2 fn: 1
  Vendor: DELL Model: PERCRAID Stripe  Rev: 0001
  Type:   Direct-AccessANSI SCSI revision: 02

Jeff Garzik proposed a scheme for ethtool that addresses somewhat similar needs for 
network interfaces. It's nice and general, and in particular works for non-PCI 
interfaces. Why not something like that for SCSI?

At 7:54 AM -0500 2001-03-21, Jeff Garzik wrote:
In various scenarios where userland needs to interact with hardware,
userland often needs to know exactly what driver (and driver version) is
currently running on a given interface.  Hotplugging and other
applications could -really- use the ability to find out bus information
for a given interface.  Firmware

So I propose the attached addition to the ethtool interface.  It adds a
new structure with several ASCII text fields, which are filled in at the
driver's discretion.  Userland then interprets these fields for their
own evil designs.

Currently (AFAIK) for all kernel interfaces, userland has no reliable
way to associate a hardware device with a kernel interface, or a driver
with a kernel interface[1].  Since we have no generic register_driver()
interface, solving this problem means implementing a domain-specific
solution like I have done here...

--
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
Index: include/linux/ethtool.h
===
RCS file: /cvsroot/gkernel/linux_2_4/include/linux/Attic/ethtool.h,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 ethtool.h
--- include/linux/ethtool.h2000/11/14 22:01:49 1.1.1.2
+++ include/linux/ethtool.h2001/03/21 12:42:15
@@ -24,10 +24,21 @@
   u32 reserved[4];
 };
 
+/* these strings are set to whatever the driver author decides... */
+struct ethtool_drvinfo {
+  chardriver[32]; /* driver short name, "tulip", "eepro100" */
+  charversion[32];/* driver version string */
+  charfw_version[32]; /* firmware version string, if applicable */
+  charbus_info[32];   /* Bus info for this interface.  For PCI
+   * devices, use pci_dev-slot_name. */
+  charreserved1[32];
+  charreserved2[32];
+};
 
 /* CMDs currently supported */
-#define ETHTOOL_GSET  0x0001 /* Get settings, non-privileged. */
+#define ETHTOOL_GSET  0x0001 /* Get settings. */
 #define ETHTOOL_SSET  0x0002 /* Set settings, privileged. */
+#define ETHTOOL_GDRVINFO  0x0003 /* Get driver info. */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSETETHTOOL_GSET

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Douglas Gilbert]

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 disk. We could also return the bus information for its
 controller(s) [remember multipathing]

Both 'cat /proc/scsi/scsi' and ioctls used on
fds belonging to the existing upper level drivers
(e.g. sd and sr) have a problem as far as getting
HBA environment information: there needs to be at
least one SCSI device (target) connected to the
HBA. With no SCSI devices connected, there is no 
fd to do an ioctl on. [The same problem arises
if a device is there but marked offline, has an
exclusive lock on it, ...]

Perhaps Matt could look at the approach I have taken
with the scsimon experimental upper level driver.
Scsimon was originally designed to get scsi based
information to the /sbin/hotplug mechanism. It also
supplies ioctls to probe HBAs as well as SCSI devices.
More information about it can be found at:
  http://www.torque.net/scsi/scsimon.html

It should not be difficult to add HBA PCI bus information
to scsimon (after the Scsi_Host structure is expanded to
hold that information).

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt_Domsch]

> 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

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

> 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 return the bus information for its
controller(s) [remember multipathing]

> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Douglas Gilbert]

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.  An
> equivalent problem (with similar solution) exists with i386 where the
> BIOS boot order is not necessarily the Linux driver load order.
> 
> 
> BIOS Enhanced Disk Drive Services 3.0 provides a way to query BIOS for
> what it thinks is it's device location and order.  IA-64 implements
> EDD 3.0, and some i386 BIOS manufactures are adding this feature
> also.  EDD 3.0 information is available at http://www.t13.org.
> 
> 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 DRIVE:466 Rev: 1.06
>   Type:   CD-ROM   ANSI SCSI revision: 02

[snip]

Matt,
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 :-) ).

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.

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt Domsch]

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 solution) exists with i386 where the
BIOS boot order is not necessarily the Linux driver load order.


BIOS Enhanced Disk Drive Services 3.0 provides a way to query BIOS for
what it thinks is it's device location and order.  IA-64 implements
EDD 3.0, and some i386 BIOS manufactures are adding this feature
also.  EDD 3.0 information is available at http://www.t13.org.

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 DRIVE:466 Rev: 1.06
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00 PCI bus: 0 slot: 2 fn: 1
  Vendor: DELL Model: PERCRAID RAID5   Rev: 0001
  Type:   Direct-AccessANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 00 PCI bus: 0 slot: 2 fn: 1
  Vendor: DELL Model: PERCRAID Stripe  Rev: 0001
  Type:   Direct-AccessANSI SCSI revision: 02


SCSI controllers which are not PCI devices would not display this
extra information.

IDE devices already provide PCI location information in
/proc/ide/ideX/config.

Furthermore, since reading /proc/scsi/scsi doesn't indicate which device
(say, /dev/sda) is which, I'd like an ioctl to query /dev/sda directly and
retrieve the PCI information.  An ioctl already exists to retrieve the
SCSI channel/id/lun information.


To do so, I propose the following:
1) Add a struct pci_dev *pci_dev member to struct Scsi_Host.
2) Add the printing function to scsi_proc.c, dependent on pci_dev != NULL.
3) Add an ioctl to scsi_ioctl.c for querying a device name like /dev/sda
directly for it's PCI information.
4) Add a line such as:
host = scsi_register (pHostTmpl, sizeof (mega_host_config));
if (!host)
goto err_unmap;
+   host->pci_dev = pdev;
  to each SCSI driver which is also a PCI device.


I've developed a proof-of-concept patch against 2.4.4-pre1, available at
http://domsch.com/linux/scsi/linux-2.4.4-pre1-scsi-pci-info-010413.patch,
in which I've modified a number of drivers.

Further work is required to change the non-trivial drivers.  By not
changing a driver, the information is simply not available, but causes no
other problems.  Drivers may be updated as time and need allow.

Additionally, on i386, I'd like to add the EDD 3.0 BIOS calls to
arch/i386/kernel/boot.S and make an edd
device driver to display such information in proc (similar to e820).

If this all works, we can remove lilo.conf guesswork like:
  bios=0x80
  disk=/dev/sda
  bios=0x81
  disk=/dev/hda
because we can query BIOS directly, and we can know exactly from
user-space, and we can actually get the SCSI driver load order
correct (assuming you trust BIOS to tell you the boot drive properly).


As always, I welcome your comments and feedback.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt Domsch]

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 solution) exists with i386 where the
BIOS boot order is not necessarily the Linux driver load order.


BIOS Enhanced Disk Drive Services 3.0 provides a way to query BIOS for
what it thinks is it's device location and order.  IA-64 implements
EDD 3.0, and some i386 BIOS manufactures are adding this feature
also.  EDD 3.0 information is available at http://www.t13.org.

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 DRIVE:466 Rev: 1.06
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00 PCI bus: 0 slot: 2 fn: 1
  Vendor: DELL Model: PERCRAID RAID5   Rev: 0001
  Type:   Direct-AccessANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 00 PCI bus: 0 slot: 2 fn: 1
  Vendor: DELL Model: PERCRAID Stripe  Rev: 0001
  Type:   Direct-AccessANSI SCSI revision: 02


SCSI controllers which are not PCI devices would not display this
extra information.

IDE devices already provide PCI location information in
/proc/ide/ideX/config.

Furthermore, since reading /proc/scsi/scsi doesn't indicate which device
(say, /dev/sda) is which, I'd like an ioctl to query /dev/sda directly and
retrieve the PCI information.  An ioctl already exists to retrieve the
SCSI channel/id/lun information.


To do so, I propose the following:
1) Add a struct pci_dev *pci_dev member to struct Scsi_Host.
2) Add the printing function to scsi_proc.c, dependent on pci_dev != NULL.
3) Add an ioctl to scsi_ioctl.c for querying a device name like /dev/sda
directly for it's PCI information.
4) Add a line such as:
host = scsi_register (pHostTmpl, sizeof (mega_host_config));
if (!host)
goto err_unmap;
+   host-pci_dev = pdev;
  to each SCSI driver which is also a PCI device.


I've developed a proof-of-concept patch against 2.4.4-pre1, available at
http://domsch.com/linux/scsi/linux-2.4.4-pre1-scsi-pci-info-010413.patch,
in which I've modified a number of drivers.

Further work is required to change the non-trivial drivers.  By not
changing a driver, the information is simply not available, but causes no
other problems.  Drivers may be updated as time and need allow.

Additionally, on i386, I'd like to add the EDD 3.0 BIOS calls to
arch/i386/kernel/boot.S and make an edd
device driver to display such information in proc (similar to e820).

If this all works, we can remove lilo.conf guesswork like:
  bios=0x80
  disk=/dev/sda
  bios=0x81
  disk=/dev/hda
because we can query BIOS directly, and we can know exactly from
user-space, and we can actually get the SCSI driver load order
correct (assuming you trust BIOS to tell you the boot drive properly).


As always, I welcome your comments and feedback.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Douglas Gilbert]

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.  An
 equivalent problem (with similar solution) exists with i386 where the
 BIOS boot order is not necessarily the Linux driver load order.
 
 
 BIOS Enhanced Disk Drive Services 3.0 provides a way to query BIOS for
 what it thinks is it's device location and order.  IA-64 implements
 EDD 3.0, and some i386 BIOS manufactures are adding this feature
 also.  EDD 3.0 information is available at http://www.t13.org.
 
 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 DRIVE:466 Rev: 1.06
   Type:   CD-ROM   ANSI SCSI revision: 02

[snip]

Matt,
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 :-) ).

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.

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

 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 return the bus information for its
controller(s) [remember multipathing]

 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Matt_Domsch]

 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

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/