[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Linux-PAM and syslog (POSIX) (fwd)



On Mon, Mar 30, 1998 at 10:59:29PM -0800, Andrew Morgan wrote:
> Theodore Y. Ts'o writes:
> >    From: Andrew Morgan <morgan@transmeta.com>
> > 	   int pam_misc_openlog( int handle, char *ident, int option, int
> > 				   facility); 
> > 	   void pam_misc_syslog( int handle, int priority, char *format,
> > 				   ...);
> > 	   void pam_misc_closelog( int handle );
> > 
> > I'd suggest using a void * for the handle, instead of an int.  Working
> 
> Before proceeding with this.  I'd like to propose that we consider an
> alternative to mimicing the old API.  One of the standard problems
> with this sort of API is that we use multiple functions to implement
> an inherently atomic request (append "this" to the log).  In other
> words, by design, we are writing code that is fraught with races
> (especially in multi threaded apps).

I'm not sure I understand you well.
Let us consider the following API:
	   int pam_misc_openlog( struct pam_log_handle * handle, char *ident,
				   int option, int facility); 
	   void pam_misc_syslog( struct pam_log_handle * handle, int priority,
				   char *format,
				   ...);
	   void pam_misc_closelog( struct pam_log_handle * handle );

where struct pam_log_handle is a private structure (known only
where the functions are implemented), something like
	   struct pam_log_handle {
		int fd;
		char *ident;
		...
	   };

Any module (or thread) should has its own handle and logs via it.
I see no race conditions with the model.

> 
> Would it be objectionable to implement logging with a single
> function?:
> 
>    pam_system_log(const char *ident, int option, int facility,
> 		  int priority, const char *format, ...);

Such an interface has a sense too. At least it's more simple.
I have no objections against the simplicity :-)

Cheers

Andrey



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []