Your suggestion jives w/ what I see in other drivers (e.g., sata using cb_ops). The problem with copying what other folks are doing is that the technology stagnates. If someone comes up with a new-and-improved infrastructure it doesn't get used if everybody keeps copying old stuff....
I'm also concerned if there's any, "standards" how the ioctl(..)s play with CIM or other management agents. Right now it seems that every bodies just doing their own thing. Fine w/ me, but if I can do better, I will. I don't want my ioctl(..)s to have surprises for anyone else who codes for them. Also, the ioctl(.. ) interface has poor support for asynchronous events (in other os's anyway). For example, a new disk gets plugged into a RAID controller doesn't mean a new LUN has been hot plugged (yet). But a management daemon may want to take note so that the new disk can get added to an available pool of disks for later use. I'm sorry if these are simple questions. I'm a jack-of-all-os's, but, unfortunately a master of none. Carlos Cyril Plisko wrote: > On Jan 31, 2008 6:37 AM, Carlos Cumming <[EMAIL PROTECTED]> wrote: > >> I'm at the point of designing the management interface to a SCSI RAID >> controller. >> >> In other os's, this controllers driver has a completely different char >> driver embedded in it just to provide an ioctl(... ) callable from >> userspace. The reason is that if there are no targets configured, >> there's no raw device entry point and so the ioctl(..)'s not available >> to userspace. Or course to create and configure a target, you need the >> ioctl(.. )...... >> >> I hope that Solaris has a better way to do this. >> >> So, the question is, what is the, "preferred" way to get to SCSI >> controller settings from user space in Solaris? >> > > I am not sure it is a preferred way, but you can always make > your driver create a "control" node (smthctl), which will be > present even without a single target available from the RAID > hardware. Then use it for all your management tasks. > I'd think it provides healthy separation between data path > and control path. > > > _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
