[PATCH] adding PCI bus information to SCSI layer

[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-xxxx.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

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: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

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.

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: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

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.

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: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

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

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.

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: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

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

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

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.

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

[Kai Henningsen]

jlundell@pobox.com (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

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

[Jonathan Lundell]

At 9:32 AM +0200 2001-05-03, Kai Henningsen wrote:
>jlundell@pobox.com (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.

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

[Chris Wedgwood]

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

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.


  --cw

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

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

[Chris Wedgwood]

On Thu, May 03, 2001 at 10:49:02AM +0100, Alan Cox wrote:

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

Hmm... so how else do you support n-forks cleanly preserving existing
semantics? I'm not sure I like Linus' suggestion, but I can't think
of anything better.



 --cw

(On the whole, I think forks are horrible enough that we shouldn't
 encourage them further than we do already with .AppleDouble, and
 similar solutions... but, opinions vary greatly here)

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

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.

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

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

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.

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

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1175 bytes --]

jlundell@pobox.com (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