> I would like propose a new project SCSI SAM Pseudo > File system in OpenSolaris. This file system will be > somewhat similar to Linux’s /proc/scsi file system, > with several extensions.
While I think there are times where a pseudo file system is a good answer to a problem, and I don't know whether or not this is one of them, I would really like to see any proposal for new ones answer the question why _that_ is a better solution than for example better (and better documented and higher stability level) kstats or USCSI/sgen functionality, or the like. In general, I like pseudo filesystems for read-only replacements to existing text files that are better presented from data actually maintained by the kernel, in that such a mechanism can be assured to be correct, complete, in sync with the kernel, and more efficient in terms of not needing heavy rewriting of a text file (which is generally _not_ a format suitable for record-level add/delete/update). In those cases, a pseudo filesystem provides compatibility for scripts that read the pre-existing file, while letting the maintenance and updating be performed by more appropriate means. But in cases where a pseudo filesystem is proposed as a _new_ way of obtaining information or control over either hardware or system state, I'm not so crazy about it. Especially where text based messages are used to communicate, because they're not efficient and probably _less_ safe than passing binary data structures back and forth (more complicated to handle by the system equals more opportunities for bugs and vulnerabilities). I'm not sure that some resemblance between hierarchical aspects of whatever is being modelled and a directory tree structure is sufficient justification for the use of such a fairly complex-to-implement approach; and I _am_ reasonably sure that controlling or even querying hardware or system state _should_not_ be brought down to the level where one can use cat, grep, awk, shell "read" commands, echo and the like to perform it. There are simply too many ways poorly written scripts can be tricked into doing horribly wrong things; which is why I tend to overuse quoting and curly braces and such; better to put them somewhere they're not needed than to leave them off of somewhere that might result in someone sneaking something in via an untrusted arg or environment variable. If one _really_ feels the need to do system-level stuff without C, it can just about all be done in perl. Most C include files can be represented well enough in perl (using h2ph and c2ph) to make it possible to use system call wrappers; or binary extensions to perl can be written. In many cases, these things already exist and have been used; so the perl kstat interface plus being able to do most ioctls or read/write of binary data from perl should be sufficient to script most actions in perl, _provided_ that existing interfaces (esp. kstats) were better documented, more consistent and complete, and more stable as to details. And perl can be _much_ safer than most shell scripts, with it's "taint" facility and other differences from typical shell languages. [...] > Apart from just these directories, this file system > will have following additional files: > > Props file: > Under every directory in this file system, a props > file will be present. This props file will have all > the properties of that particular directory > > Following are the props file contents for each > directory > a) /system/scsidev/localhost: Details about the > system, architecture etc. > b) HBA directory: Details about the card, vendor, > device id, controlling driver name, FW version > number, type of boot code, subsystem id, device id > etc. > c) Port directory: Port WWN or id number, port speed, > port state target count etc. > d) Target directory: Target’s inquiry data, its port > number (WWN) etc > e) Lun directory: Lun properties like lun state, lun > number etc > > NVRAM, VPD, Firmware data: > The NVRAM image, VPD data, FW image, BIOS will be > represented as files under the HBA directory for each > HBA. The VPD or NVRAM image can be obtained using cat > command. Update of FW or other image can be done as a > file I/O itself. > Adapter Command Interface (cmd_port): > Each of the directories will have cmd_port apart from > the props file. This is a write only file through > which commands to that layer will be sent. > > For example to reset the adapter chip the command > could be: > echo reset > > /system/scsidev/localhost/QLA2462/cmd_port > > To send inquiry command to a lun2 > echo scsi inquiry> > /system/scsidev/localhost/QLA2462/target1/lun2/cmd_por > t Many/most SCSI commands are actually initiating a dialogue; even if some means is found so that one can choose between assuredly getting the reply and ignoring it (without having unread replies backing up), ignoring the replies isn't likely to be sensible or sane. A read/write interface (and worse still in text format) IMO offers more opportunities for misuse than it does benefits in terms of trivially easy access. Worse still, damnably difficult problems can crop up with something as simple as a bad cable, where software means alone not only don't make the problem obvious, but much of what you attempt simply hangs. When you add to that all the things that could go wrong by opening an invitation to amateurs to think that they can write e.g. a user-space SCSI scanner driver as a shell script (which although absurd sounding, your interface might well enable), what you may see as a great expansion of access to functionality, I see as an _explosive_ expansion of situations that are likely to cause expensive down-time and need expensive troubleshooting. > Extensions: > Fibre Channel Switches: > The Fibre Channel switches directory could be > included under the port directory. This represents > the FC switch and properties of port under the > switch. There's certainly some room for extended FC inquiry and management functionality, IMO. The only opinion I have about how that should be modelled is that my skepticism of the pseudo-fs approach definitely applies, although I wouldn't presume to exclude it entirely (provided it _does_not_ introduce a bunch of text-like "files"). > Remote systems’ properties: > The whole file system structure could be mounted into > a remote machine, provided with appropriate security > credentials and interoperability with NFS file > system. Hmm. Good and bad. Although I never had a chance to play with it enough to see what it could do, I recall that the long-gone RFS could provide remote access to device files; indeed, that a FIFO on RFS could be used by processes on different systems (not sure if that was only the server and a client, or even two clients of the same RFS share) to communicate with one another. What I never did understand is how (if at all) that worked with ioctls, since their interpretation is only meaningful as applied to a particular implementation of a particular driver - the 3rd arg to ioctl could be anything, and it's not like XDR or C++ RTTL; it's neither got a universal form, nor is its structure self-defining. OTOH, eliminating ioctls from the picture, and for a limited subset of devices that speak a somewhat common language (SCSI protocol, give or take differences is target or LUN representation among narrow, wide, FC, iSCSI, etc), it _might_ have the opportunity to be useful. But in general, I think high-functional iSCSI gateways ought to be capable of providing e.g. remote control of CD/DVD burners, changers, scanners, and all sorts of other non-disk SCSI speaking devices, and that that would be more appropriate than NFS-mounting a pseudo filesystem (and would allow finer-grained control, i.e. per target/initiator pair, with authentication). > So the directory /system/scsidev/localhost will have > the following entries > > cmd_port > props > QLA2432/ > QLA2432/port0 > QLA2432/port0/props > QLA2432/port0/cmd_port > QLA2432/port0/target0/ > QLA2432/port0/target0/props > QLA2432/port0/target0/cmd_port > QLA2432/port0/target0/lun0 > QLA2432/port0/target0/lun0/props > QLA2432/port0/target0/lun0/cmd_port > QLA2432/port0/target0/lun0/lun > and so on I applaud the imagination, and I wouldn't want to discourage the exploration of ideas, but (as is perhaps too often the case), I foresee the problems likely outweighing the benefits, although I'd like to think I'm open to being convinced otherwise. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
