[ ... ]
> > BTW, I am still expecting from you the text of the PCI specifications, you
> > seemed to refer to, about device specific configuration space being
> > required to allow reads without side effect. It will not be a problem if
> > you didn't find this text, since I didn't find it too.
>
> I tried to look it up, but I failed. It was either my own fantasy motivated
> by "the spirit of PCI" :) or there is some obscure notice at some obscure place
> I didn't look at now (aka unable to grep on dead trees :)).
I did the same and probably some other people who read postings about this
question. So, such a notice very probably does not exist.
> > Anyway, real software must take into account real hardware.
>
> We _do_ take into account real hardware. We already disallow access to
> anything else than the standard header to ordinary users. Root is expected
> to know what he is doing and system interfaces should not be obscurified
> just to make the machine uncrashable by root who types commands he doesn't
> understand. /proc/ioports is just the same story and nobody is worried
> about it -- do you see any difference?
I see a _great_ difference because I think that people are not stupid
enough to believe that reading ioports had no side effects.
If no side effects reading the device specific PCI address space is not
specified as required, it seems to be at least _implicitely_ _assumed_
even by people who really read the PCI specifications. As a result, we
must not require users to be aware of the risk of breaking their system by
submitting a command that read more than 64 bytes of PCI configuration
space.
I would accept the following approach for the reading of the device
specific PCI address range:
1 - No side effects explicitely required:
- Can be configurable as a standard feature.
- Handle a black list.
- Require some special configuration option or command option for
bypassing the black-list.
2 - Side effects allowed:
- Must be configured as experimental if no white list is hanlded.
- Can be configured as a standard feature if a white list is handled.
3 - No side effects implicitely assumed:
- Must be configured as experimental if no while/black list.
- Can be configured as a standard feature if either a white list or
a blacklist is handled.
- You may add some special option that allows bypassing the black
list.
I vote for 3(black-list) that is not different from 1. I only suggest to
add at least a black list for this feature.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/