On 23.12.2010, at 00:35, Benjamin Herrenschmidt wrote: > On Thu, 2010-12-23 at 00:23 +0100, Alexander Graf wrote: >>> The non working compat ioctl is one, the fact that "sg" has >>> no /sys/class/block (or /sys/block) entries is another, etc... Ie, >> we >>> are faced with a problem with Linux not exposing those informations >> in >>> an easy to retrieve way, and no proper cross-platform way to obtain >>> those informations neither. >> >> Why would you care about cross-platform here? Not saying I fully >> understand what information exactly you're lacking. But it's either >> SG_IO max request size in which case you don't need any equivalent on >> other platforms, as it's not available anywhere else. Or it's >> something else in which case you can just set it to some "safe" small >> default value and call it a day :). > > Well, do we support something like scsi-generic on windows or BSD > hosts ? dunno.. .just asking :-) They -have- mechanisms (at least > windows do) to pass SCSI requests down the stack. In that case, they'll > have similar limitations (at the very least the max request size). > > So we'd want some way to expose that... but if scsi-generic today is > linux only, then I can try to add linux-isms in there as a stop-gap to > try to at least retreive the max req. size which is the main issue for > me right now... at least until I start trying to have the SG_IO > read/write directly into guest memory without bouncing :-) At that > point, the SG limits might become trouble as well.
This all belongs in the block layer. If you create a call back function or property in the block struct, windows can implement its own limits when someone sits down to implement SG_IO on Windows. Alex
