> Such a library would be great. > > I like your dessert topping list, but we should want an option for code > that's not going to use an interface like the one you described. > Imagine an attribute (ioctl?) on named pipes that causes the pipe to > discard contents when there's no reader. Then SMF could set the > stdour/stderr of every start method to be such a named pipe, and a > service could read from all those named pipes and route to: rotateable > service log files, syslog, ... > > > I'd like to see some of the folks in Fishworks and elsewhere in > > our org collaborate on this. When I think about how we should do > > error reporting when CIFS and Kerberos talk to each other, this is > > where I really see an increasing need for something like this. > > I agree, but anything to do with FOSS (libldap, libsasl, SASL, Kerberos, > OpenSSL, ...) immediately gets complicated. There are things that can > be done simply enough, and others that can't be done without upstream > negotiation or forking. (I'm not trying to be a naysayer, just setting > expectations.) The good news is that a few changes in libldap will go a > _long_ way -- libldap is the most gratouitous obfuscator of error > messages that we have. > > Nico
Definitely. But many of the FOSS libraries have some kind of central point that can either be hooked, or we can have standard "glue" that you can call from our code if the library fails, that gets its error state and then puts it into our thing. Take OpenSSL as an example: It always call SSLerr, which does ERR_put_error or whatever their magic underlying thing is. In current Fish code, we have a single wrapper ak_ssl_error() which is called right after any SSL call fails, which retrieves their error state using the ERR_* interfaces and then puts the right stuff into our logging mechanisms. Or you can imagine, equivalently, that in Solaris, our port could modify ERR_put_error directly to do that, leaving the rest of the error-producing SSL code alone. I'm not familar with all of the other components above at the source level, but hopefully most are amenable to something similar to that. -Mike -- Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/
