Carlos Cumming wrote: > 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....
Until somebody or some organisation comes up with something better, this will do. What we have now works quite well, imnsho. > 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. Surely the way around that is to publicly document your ioctl operations in detail so that anybody who wants to make use of them knows exactly what they are getting? > 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. You should check out the syseventd(1M) system. There are headers for it in /usr/include/sys/sysevent. There is also a userland management library libsysevent(3LIB). James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
